- GNU Screen 5.0.0 および setuid-root インストールで深刻なセキュリティ脆弱性が発見された
- 主な問題は ローカルでの root 権限昇格、TTY ハイジャック、ワールド書き込み可能な PTY の生成 など
- 多くの Linux および UNIX ディストリビューション が一部または全部の影響を受ける
- 暫定パッチが提供 されており、多くのディストリビューションで優先的な対応が必要
- Screen の setuid-root 設計自体に 根本的なセキュリティリスクが存在 する
1. 紹介
- 2024年7月、Screen の upstream メンテナが コードレビューの依頼 を行ったことをきっかけにセキュリティレビューが始まった
- 以前は特に問題が見つからなかったが、今回は Screen 5.0.0 を setuid-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件のコメント
Hacker Newsのコメント
tmateのようなツールが可能なのだと思う。tmuxにも同じ脆弱性があるのか気になるtmuxは Unix ドメインソケットを使っている。なぜscreenが setuid 方式を使ったのか理解できない。root 権限は不要に見える。TFA の説明によれば、現在のscreen開発者たちはコードベースを完全には把握しておらず、setuid-root 方式のほうが機能を実装しやすかったのでそれを選んだようだscreen -x <特定ユーザーのウィンドウ>に制限することで、その学生がそのscreenACL で許可されたウィンドウだけを使えるようにしていた。私はプロジェクターで各学生の画面を一人ずつ確認して映していた。ただ、セキュリティホールだらけだとしても驚きはないscreen -xコマンドを使った経験があるutmpグループに SETGID が設定されている。これが何を意味するのかはよく分からないscreenに suid は付いていないtmux作者とのQ&Aもあり、16年前からドキュメント不足への不満があった。関連資料: https://undeadly.org/cgi?action=article&sid=20090712190402rkhunterのようなツールでカバーされてきたし、90年代にもscreenは setuid root だったはずだscreenに新しいウィンドウを追加できる機能があるのかも気になるtmuxなどの代替はあっても、多くの人が長年 Screen を使ってきた。ツールの老朽化は惜しいtmuxは OpenBSD の標準に 4.6 から入っていたと記憶しており、監査も受けている。よりセキュリティを重視する人には良い代替だscreenへの言及を見て、昔tmuxに移行したあと、うっかりscreenを使わなくなって混乱していた記憶を思い出したscreenと setuid が言及されているのは面白い。以前、奇妙な問題を解決するためにscreenにchmod u+sを付けたことがあった。そんなことをしなければならないのは変な気分だった。しかし調べてみると、screenには setuid に依存する機能があり、システムによっては最初からそのように配布されていることが分かった。そしてu+sを付けると、screenは自分の~/.screenrcではなく root の~/.screenrcを読んだ(その場しのぎとして受け入れた)。screenのビルドごとに setuid 対応が違う可能性もあると思う