2 ポイント 投稿者 GN⁺ 2025-05-14 | 1件のコメント | WhatsAppで共有
  • GNU Screen 5.0.0 および setuid-root インストールで深刻なセキュリティ脆弱性が発見された
  • 主な問題は ローカルでの root 権限昇格、TTY ハイジャック、ワールド書き込み可能な PTY の生成 など
  • 多くの Linux および UNIX ディストリビューション が一部または全部の影響を受ける
  • 暫定パッチが提供 されており、多くのディストリビューションで優先的な対応が必要
  • Screen の setuid-root 設計自体に 根本的なセキュリティリスクが存在 する

1. 紹介

  • 2024年7月、Screen の upstream メンテナが コードレビューの依頼 を行ったことをきっかけにセキュリティレビューが始まった
  • 以前は特に問題が見つからなかったが、今回は Screen 5.0.0setuid-root 設定 で使用した場合に深刻な root 権限昇格の脆弱性が見つかった
  • さらに、旧バージョン(4.9.1 など) にも影響する軽微なセキュリティ脆弱性が複数確認された
  • レポートには バージョン別の脆弱性パッチセット(4.9.1、5.0.0)が添付されている
  • ディストリビューションごとの Screen 設定とバージョン、主要脆弱性、setuid-root に関する開発上のリスク、セキュリティ強化の推奨事項、公開調整プロセスの問題点、影響マトリクスなどが含まれる

2. Screen の構成とバージョン概要

  • 2024年8月に Screen 5.0.0 がリリースされ、Arch Linux、Fedora 42、NetBSD 10.1 に搭載された
  • 5.0.0 には多数のリファクタリングが含まれており、その一部は10年以上前から存在するコードに由来する
  • 一部の脆弱性は 5.0.0 で新たに導入され、一部は 旧バージョン(4.9.1 など) にも存在する
  • 大半のディストリビューションでは依然として 4.9.1 が使われている
  • Screen のマルチユーザーモード は setuid-root でインストールされた場合にのみ利用可能であり、コードの複雑さによって攻撃面が大きく増える
  • 主要ディストリビューションのうち Arch Linux、FreeBSD、NetBSD は Screen を setuid-root でインストールしている。Gentoo は “multiuser” USE flag の場合にのみ setuid-root でインストール可能

3. セキュリティ問題の詳細

3.a) logfile_reopen() によるローカル root 取得 (CVE-2025-23395)

  • Screen 5.0.0 を setuid-root で実行した際、logfile_reopen() 関数が権限を落とさないまま、ユーザー入力のパスでファイルを作成する
  • 攻撃者は root 所有の任意ファイルを作成し、端末データを記録して悪用できる
  • 既存ファイルも悪用可能で、たとえば特権付き shell script へのコード挿入といった攻撃が可能になる
  • Arch Linux、NetBSD 5.0.0 では完全に脆弱で、Fedora や Gentoo の特定環境でも部分的に脆弱
  • パッチは安全なファイル処理の復元として適用されており、ディストリビューションごとに具体的な影響差がある

3.b) マルチユーザーセッション接続時の TTY ハイジャック (CVE-2025-46802)

  • Attach() 関数で multiattach フラグが有効になると、TTY の権限が一時的に 0666 に変更される
  • この過程で race condition により、第三者のユーザーがその TTY に読み書きアクセス できるようになる
  • 入力データの盗聴、データ改ざん、パスワード窃取などのリスクがある
  • TTY 権限が元に戻らないコードパスも存在する
  • パッチは chmod 666 操作の削除として適用された。ただし一部の再接続ユースケースは壊れる可能性があるが、従来も正常には動作していなかった

3.c) PTY のデフォルト権限の脆弱性 (CVE-2025-46803)

  • 5.0.0 では PTY のデフォルト権限が 0620 → 0622(ワールド書き込み可能) に変更されていた
  • セキュリティ上の潜在リスクが高まり、特に全ユーザーが他人の PTY に書き込めるようになる
  • この変更は誤って導入されたものとみられ、パッチはコンパイル時の安全なデフォルト(0620)を復元することで対処する
  • Arch Linux、NetBSD が主な影響対象

3.d) ソケットエラーメッセージによるファイル存在情報の漏えい (CVE-2025-46804)

  • SCREENDIR 環境変数と Error メッセージを使うことで、実在するファイル/ディレクトリの有無を root 権限で確認可能 になる
  • 軽微な情報漏えいだが、すべての setuid-root インストール環境でリスクがある

3.e) シグナル送信における TOCTOU race condition (CVE-2025-46805)

  • CheckPid()Kill() 関数の間の時間差により、意図しない PID に root 権限でシグナルが送られる恐れがある
  • 主に SIGCONT、SIGHUP などしか許可されていないため影響は限定的だが、サービス拒否(DoS)や軽微な完全性の毀損が起こり得る

3.f) 誤った strncpy() 使用によるコマンド送信時のオーバーフロー

  • 5.0.0 では strncpy() の誤用によりバッファオーバーフローとプログラムクラッシュ が発生する
  • 適切に修正されない場合、コマンド送信時に MAXPATHLEN 以降のメモリを上書きし、サービス不能状態につながる
  • セキュリティ問題ではないが、安定性の観点から早急な修正が必要

4. setuid-root 実装に関連する追加リスク

  • マルチユーザーモードで 複数ユーザーの UID 処理ロジックの不備 が確認された
  • setuid-root 状態での drop privilege ロジックが不完全
  • root が作成したセッションでは効果的な権限低下が行われず、全体としてリスクが高い

5. セキュリティ強化に関する一般的な推奨

  • 大規模なコードリファクタリングの過程で 既存のセキュリティロジックの崩壊 が確認された
  • setuid-root バイナリの性質上、セキュリティテストスイートの導入と、すべてのファイルシステム/環境変数処理を保守的に設計する必要がある
  • 特に setuid-root での全面実行は推奨されず、multi-user 機能は信頼されたグループによる opt-in 方式に限定すべき
  • 環境変数(PAH など)は信頼されたパスのみを指定できるよう必ず強制すべき

6. 脆弱性公表の調整プロセスにおける問題点

  • Upstream との 調整プロセスが非効率的に進み、パッチ開発と公開が遅延する問題が発生した
  • Upstream 側のコード理解や対応能力の不足により、緊密な対応が難しかった
  • 最終的にはディストリビューション側がパッチ開発を主導し、調整された日程に合わせてレポートを公表した
  • Screen プロジェクト自体の 保守・運営能力の不足 も確認された

7. 影響マトリクス

  • Arch Linux(5.0.0, setuid-root): 3.a, 3.b, 3.c, 3.d, 3.e, 3.f のすべての脆弱性の影響を受ける
  • Debian/Ubuntu など多くのディストリビューション: 3.b(部分的影響)
  • Fedora 42(5.0.0, setgid-screen): 3.b(部分的影響)、3.f の影響
  • Gentoo(4.9.1, setgid-utmp): 3.b(部分的影響)、unstable ebuild + multiuser USE flag では 5.0.0 と同様の影響
  • FreeBSD 14.2(4.9.1, setuid-root): 3.b, 3.d, 3.e の影響
  • NetBSD 10.1(5.0.0, setuid-root): 3.a, 3.b, 3.c, 3.d, 3.e, 3.f の影響
  • OpenBSD 7.7(4.9.1): 3.b(部分的影響)
  • openSUSE TW: 3.b(部分的影響)

8. 日程

  • 2024-07-01: upstream からコードレビュー依頼を受領
  • 2025-01-08: レビュー開始
  • 2025-02-07: upstream に非公開で脆弱性を報告し、調整済み公開を要請
  • 2025-02~04: パッチ議論を進行、embargo 期間の問題で日程を再調整
  • 2025-05-12: 本レポートおよび公式発表を実施

9. 参考リンク

  • GNU Savannah [Screen プロジェクトページ]
  • openSUSE Bugzilla、関連パッチ、参考 CVE、バグレポートおよびドキュメントリンクを含む

1件のコメント

 
GN⁺ 2025-05-14
Hacker Newsのコメント
  • Screenには複数ユーザーが同じセッションに接続できるマルチユーザーモードがある。この機能があるから tmate のようなツールが可能なのだと思う。tmux にも同じ脆弱性があるのか気になる
    • tmux は Unix ドメインソケットを使っている。なぜ screen が setuid 方式を使ったのか理解できない。root 権限は不要に見える。TFA の説明によれば、現在の screen 開発者たちはコードベースを完全には把握しておらず、setuid-root 方式のほうが機能を実装しやすかったのでそれを選んだようだ
    • この機能は本当に素晴らしい。トレーニングセッションでは、学生ごとに自分のノートPCへのログインアカウントを渡し、ssh シェルを screen -x <特定ユーザーのウィンドウ> に制限することで、その学生がその screen ACL で許可されたウィンドウだけを使えるようにしていた。私はプロジェクターで各学生の画面を一人ずつ確認して映していた。ただ、セキュリティホールだらけだとしても驚きはない
    • screen -x コマンドを使った経験がある
  • Debian では GNU screen は setuid root 権限付きではインストールされていない
    • Debian Stable(bookworm)のパッケージは古すぎるため 5.0.0 の脆弱性の影響を受けない。以前は Debian のソフトウェアバージョンの遅さが嫌だったが、今は必要な一部のアプリケーションだけ別のパッケージソースで新しい版を使い、それ以外は古い版でも問題なく使っている
    • Gentoo も同様。ただし Gentoo では utmp グループに SETGID が設定されている。これが何を意味するのかはよく分からない
    • Slackware 15 では screen に suid は付いていない
    • Fedora では setuid でインストールされているようだ
  • ブログ記事のレンダリング版の紹介: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • GNU Screen のログファイル記録機能について文書が不足しているので記事の著者にメールを送った。GNU にはもっと良い issue tracking system が必要だと思う。関連資料: http://www.zoobab.com/screenrc
  • observed behaviour は 2005年から Screen に存在していた。アンチパターンとして長年 rkhunter のようなツールでカバーされてきたし、90年代にも screen は setuid root だったはずだ
  • upstream(公式開発チーム)が今回関与していたことに驚いた。5年ほど前に GNU screen の開発が完全に止まったように見えて残念だった。今もそうなのか気になるし、画面に attach せずに screen に新しいウィンドウを追加できる機能があるのかも気になる
    • upstream が SUSE チームにレビューを依頼した。開発リソースが不足していて、現在は十分にメンテナンスされていないようだ。もしそうなら残念だ。tmux などの代替はあっても、多くの人が長年 Screen を使ってきた。ツールの老朽化は惜しい
    • 関与したのは setuid-root で配布したことだけだ。この設定で配布しているディストリビューションだけが脆弱で、それ以外は影響を受けない。公式パッチが遅いときはディストリビューション側で直接パッチを当てる
    • GNU ツールの開発が止まること自体(バグ修正は別として)は、必ずしも悪いことではないと思う。機能が十分に完成しているというサインかもしれない
    • upstream とのコミュニケーションが難しく、バグ修正やリリースの詳しい情報は持っていない。セキュリティレビューの依頼はしたが、連絡が取りにくい状況のようだ
    • オープンソースでは、あるソフトウェアが終わって代替が出てきても、すぐに移行する動機が弱く、惰性が生まれる問題がある。逆に商標だけ買って中身を完全に別物にしてしまう例もある(Audacity のように)。良い解決策はない
  • レンダリング版へのリンク: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • 人気のあるオープンソースツールを、どれだけ多くの開発者が実際に全部使っているのか気になるし、それらのツールを使う分野でどれほどのお金が動いているのかも気になる
  • tmux は OpenBSD の標準に 4.6 から入っていたと記憶しており、監査も受けている。よりセキュリティを重視する人には良い代替だ
    • screen への言及を見て、昔 tmux に移行したあと、うっかり screen を使わなくなって混乱していた記憶を思い出した
  • screen と setuid が言及されているのは面白い。以前、奇妙な問題を解決するために screenchmod u+s を付けたことがあった。そんなことをしなければならないのは変な気分だった。しかし調べてみると、screen には setuid に依存する機能があり、システムによっては最初からそのように配布されていることが分かった。そして u+s を付けると、screen は自分の ~/.screenrc ではなく root の ~/.screenrc を読んだ(その場しのぎとして受け入れた)。screen のビルドごとに setuid 対応が違う可能性もあると思う
    • setuid はもともとそういう動作だ。バイナリに特殊ビットを設定すると、常に指定されたユーザーとして実行せよという意味になる