GNU Screenで発見された複数のセキュリティ問題

 (openwall.com)
2 ポイント 投稿者 GN⁺ 2025-05-14 | 1件のコメント | WhatsAppで共有
  • GNU Screenのセキュリティレビューで、Screen 5.0.0 と setuid-root インストールを中心に、ローカル権限昇格、TTYハイジャック、情報漏えい、シグナル送信の競合状態、コマンド送信クラッシュが確認された
  • 最も深刻な CVE-2025-23395 では、logfile_reopen() がユーザー指定パスを root 権限で処理し、任意の場所に root 所有ファイルを作成したり、既存ファイルにログを追記したりできる
  • マルチユーザーモードの古い挙動も問題として明らかになり、Attach() が TTY を一時的に 0666 に変更することで、他ユーザーによる読み書きや入力注入が可能になる
  • ディストリビューションごとのリスクはインストール方式によって分かれ、Arch Linux と NetBSD 10.1 は Screen 5.0.0 を setuid-root で提供しているため、主要な脆弱性の影響を大きく受ける
  • 現在の推奨は Screen を setuid-root でインストールしないことであり、マルチユーザー機能には信頼済みグループベースの opt-in、デフォルトでの権限降格、限定的な権限昇格、環境変数の整理が必要とされる

公開の背景とパッチ

  • 2024年7月、upstream の Screen メンテナーが現行コードベースのレビューを依頼し、実際のセキュリティレビューは 2025年1月に開始された
  • レビューの結果、Screen 5.0.0 の主要アップデートで、setuid-root ディストリビューションに影響するローカル root エクスプロイトが発見された
  • さらに深刻度の低い問題も確認され、その一部は多くのディストリビューションに残る Screen 4.9.1 およびそれ以前のバージョン にも影響する
  • 問題は 2025年4月30日に distros メーリングリストへ共有され、2025年5月12日に公開された
  • 報告にはバージョン別のパッチ一式が添付されている

Screen の構成とマルチユーザーモード

  • Screen 5.0.0 は 2024年8月に upstream から主要リリースとして公開され、Arch Linux、Fedora 42、NetBSD 10.1 がこのバージョンを提供している
  • 多くの Linux および UNIX ディストリビューションは、執筆時点でも依然として Screen 4.9.1 を使用している
  • Screen の マルチユーザーモード は、適切な認証情報がある場合に、他ユーザー所有の Screen セッションへ attach できるようにする
    • この機能は Screen が setuid-root ビット付きでインストールされている場合にのみ利用可能
    • 複雑な Screen コードが root 権限で実行されるため、攻撃対象領域が広がる
  • レビュー対象システムのうち、Arch Linux、FreeBSD、NetBSD は Screen を setuid-root でインストールしている
  • Gentoo Linux では "multiuser" USE フラグが設定されていると setuid-root ビットが適用される
  • 一部ディストリビューションは setuid の代わりに setgid を使用している
    • Gentoo Linux のデフォルトは setgid-utmp で、Screen はシステム全体の utmp データベースにログイン記録を作成できる
    • Fedora Linux は setgid-screen で、Screen は /run/screen のシステム全体ディレクトリにソケットを配置できる

CVE-2025-23395: logfile_reopen() のローカル root エクスプロイト

  • CVE-2025-23395 は、Screen 5.0.0 が setuid-root 権限で実行される場合に影響する
  • logfile_reopen() 関数はユーザー指定パスを処理する際に権限を降格しない
  • 非特権ユーザーは任意の場所に次の属性を持つファイルを作成できる
    • 所有者: root
    • グループ: 呼び出しユーザーの実グループ
    • ファイルモード: 0644
  • 既存ファイルも悪用可能である
    • Screen PTY に書き込まれたデータがそのファイルに append される
    • 既存ファイルのモードや所有権は変更されない
  • Screen はログファイルを最初に開く際には正しく権限を降格するが、ログファイルを再オープンすべきと判断した瞬間に権限昇格の可能性が生じる
  • stolen_logfile() チェックで元のログファイルの link count が 0 になったり、サイズが予期せず変化したりすると logfile_reopen() が呼ばれる
  • この条件は非特権ユーザーが意図的に誘発できる
  • Screen 5.0.0 向け patch 0001 は、ログファイル再オープン処理に安全なファイル処理を再導入する
  • この問題は古い commit 441bca708bd で lf_secreopen() が削除されたことで発生し、その変更が 5.0.0 リリースに含まれた

CVE-2025-46802: マルチユーザーセッション attach 中の TTY ハイジャック

  • CVE-2025-46802 は multiattach フラグが設定された Attach() 関数で発生する
  • Screen はマルチユーザーセッション attach 時に、現在の TTY に対して chmod() でモードを 0666 に変更する
  • TTY パスは /dev 配下かどうかや isatty() 条件などで検証されるため、この挙動だけで別個のローカル root エクスプロイトにはならない
  • 問題は、TTY 権限が一時的に緩和されている間、他ユーザーがその TTY を読み書きできる 競合状態 が生じる点にある
  • Linux の inotify API ベースの簡単なテストでは、Python スクリプトが 2〜3 回に 1 回の試行ごとに影響を受ける TTY を開けた
  • 攻撃者は次のことが可能である
    • TTY に入力されるデータを盗聴する
    • TTY にデータを注入する
    • ユーザーを誤誘導してパスワードを入力させる
    • 制御シーケンスを注入して被害者を混乱させたり、関連するターミナルエミュレータの問題を突いたりする
  • Attach() の一部の return 経路では元の TTY モードが復元されない
    • 例: 対象セッションが見つからず、"quiet" 引数が設定されている場合
  • パッチは一時的な chmod() を削除する
    • Screen 4.9.1 向け patch 0001
    • Screen 5.0.0 向け patch 0004
  • 公開直前に、このパッチが一部の reattach ユースケースを壊す可能性が確認されたが、そのユースケースは Screen 4.9.1 でもすでに壊れていたことが確認された
  • この問題は少なくとも 2005年以降の Screen バージョンに存在し、setuid-root でマルチユーザー対応を提供する Linux ディストリビューションおよび BSD に影響する
  • setuid-root でない場合でも、ユーザーは自分の TTY モードを変更する権限を持つため理論上は影響を受けるが、Screen は root 権限なしでは他ユーザーのセッションに対して処理を続行しない

CVE-2025-46803: Screen 5.0.0 の world-writable PTY デフォルト

  • CVE-2025-46803 は、Screen 5.0.0 で Screen が割り当てる PTY のデフォルトモードが 0620 から 0622 に変わった問題である
  • このデフォルトでは、システム上の誰でも Screen PTY に書き込める
  • セキュリティ上は CVE-2025-46802 と似た問題が生じるが、情報漏えいの側面は除かれる
  • Screen 4.9.1 ではコードレベルのデフォルト値は 0622 だったが、autotools 構成のデフォルト値 0620 が適用され、安全なデフォルトが使われていた
  • Screen 5.0.0 では configure.ac が書き直され、autoconf レベルの 0620 デフォルトが失われ、その後 pty-mode configure スイッチがデフォルト 0622 として再導入された
  • 5.0.0 のリリースノートは見当たらず、ChangeLog の一部項目しかなく、PTY モードのデフォルト変更は意図的な判断には見えない
  • Screen 5.0.0 向け patch 0002 は configure.ac で安全なデフォルト PTY モードを復元する
    • 変更を適用するには autoreconf の実行が必要
  • パッケージャーには --with-pty-mode=0620 configure スイッチを明示的に渡すことが推奨される
  • Gentoo Linux と Fedora Linux は安全な --with-pty-mode を明示的に渡している
  • Arch Linux と NetBSD はこのスイッチを渡しておらず、新しいデフォルト値が適用されて脆弱である

CVE-2025-46804: ソケットパスのエラーメッセージによるファイル存在有無の漏えい

  • CVE-2025-46804 は、Screen が setuid-root 権限で実行される場合に発生する軽微な情報漏えいである
  • 古い Screen バージョンと 5.0.0 の両方で確認されている
  • Screen は SocketPath を root 権限でチェックし、非特権ユーザーが通常は知り得ないパス情報をエラーメッセージで露出する
  • SCREENDIR 環境変数を使うと、次の情報を推測できる
    • /root/.lesshst が通常ファイルかどうか
    • /root/.cache ディレクトリが存在するかどうか
    • /root/test パスが存在しないこと
  • パッチは、setuid-root インストールで対象パスがプロセスの実 UID によって制御されていない場合、一般的なエラーメッセージのみを出力するよう変更する
    • Screen 4.9.1 向け patch 0002
    • Screen 5.0.0 向け patch 0005
  • レビューしたすべてのディストリビューションが影響を受ける

CVE-2025-46805: シグナル送信の TOCTOU 競合状態

  • CVE-2025-46805 は、setuid-root コンテキストでユーザー指定 PID にシグナルを送る際に生じる TOCTOU 競合状態である
  • CheckPid() は実ユーザー ID へ権限を落としたうえで、カーネルが対象 PID へのシグナル送信を許可するかを確認する
  • 実際のシグナルは後で Kill() を通じて送られ、この際に root 権限が使われる可能性がある
  • チェックと実際の送信の間に、先ほど確認した PID が別の privileged process に置き換わる可能性がある
  • privileged な Screen デーモンプロセスが自分自身にシグナルを送るよう騙される可能性もある
  • 現時点で送れるのは SIGCONT と SIGHUP のみであるため、影響はローカルサービス拒否または軽微な完全性侵害にとどまる可能性が高い
  • この問題は CVE-2023-24626 の不完全な修正に由来する
    • その修正前は、競合状態がなくても任意プロセスへこれらのシグナルを送ることができた
  • パッチは、実際のシグナルも CheckPid() と同様に実 UID 権限で送るよう変更する
    • Screen 4.9.1 向け patch 0003
    • Screen 5.0.0 向け patch 0006
  • レビューしたすべてのディストリビューションが影響を受ける

Screen 5.0.0 の strncpy() 使用によるコマンド送信クラッシュ

  • Screen 5.0.0 には、セキュリティ問題とは見なされていないが優先的に修正すべき strncpy() 関連の問題がある
  • commit 0dc67256 で複数の strcpy() 呼び出しが strncpy() に置き換えられた
  • strncpy() は安全な文字列処理のための関数ではなく、固定長バッファを 0 でパディングする関数であるため、最初の \0 バイト以降も宛先バッファ末尾まで 0 を書き込む
  • attacher.c のコマンドライン引数処理ループでは、最初の反復後も宛先サイズとして MAXPATHLEN を渡している
  • ポインタ p がすでに進んだ後でも同じサイズを渡すため、その後の strncpy() 呼び出しはバッファ末尾を越えて \0 バイトを書き込む
  • Arch Linux で実行中の Screen セッションに 2 つ以上のコマンド引数を送ると、_FORTIFY_SOURCE が有効なビルドで次のエラーが観測された
    • *** buffer overflow detected***: terminated
    • Aborted (core dumped)
  • _FORTIFY_SOURCE がなければ目に見えるエラーが出ないことがあり、-fsanitize=address でもエラーが見えない場合がある
  • 呼び出し元は cmd バッファの後ろにある MAXPATHLEN バイトを 0 で上書きできるが、直後に同じサイズの writeback[MAXPATHLEN] バッファがあるため、攻撃者に有利に悪用できる可能性は低いと判断されている
  • Screen 5.0.0 向け patch 0003 は strncpy() を snprintf() に置き換え、残りの宛先バッファサイズを正確に渡す
  • Screen 5.0.0 を提供するすべてのディストリビューションが影響を受ける

ディストリビューション別の影響範囲

システム Screen バージョン 特権 影響
Arch Linux 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10 4.9.0 なし 3.b の一部
Ubuntu 24.04.2 4.9.1 なし 3.b の一部
Fedora 42 5.0.0 setgid-screen 3.b の一部, 3.f
Gentoo 4.9.1 setgid-utmp、multiuser USE フラグ設定時は setuid-root 3.b の一部
openSUSE TW 4.9.1 なし 3.b の一部
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 の一部

setuid-root 設計への懸念と推奨

  • Screen のマルチユーザーモードには 3 つの UID が関わる
    • privileged operation のための effective UID 0
    • セッションを作成したユーザーの実 UID
    • セッションに attach するユーザーの実 UID
  • 現在の Screen コードは、この区別を適切に反映するのが難しい構造に見える
  • root が作成した Screen マルチユーザーセッションは、セッション作成者の実 UID である 0 に「権限降格」するため、実質的に権限降格が起きない
  • Screen 5.0.0 のリファクタリング過程で、長年存在していたセキュリティロジックが壊れ、その結果として CVE-2025-23395 と CVE-2025-46803 が発生した
  • さらなるリファクタリングの前に、実装のセキュリティ特性を検証できるテストスイートが必要である
  • setuid-root バイナリを扱う開発者は、その領域のリスクを理解していなければならない
  • Screen は昇格した権限のまま動作し続け、危険と見なす操作でのみ選択的に権限を下げている
  • 堅牢な setuid-root プログラムは、デフォルトで権限を下げ、実際に昇格権限が必要な操作でのみ権限を上げる方式であるべきだ
  • setuid-root コンテキストでは、明示的に許可された環境変数だけを残して削除するロジックが必要である
  • PATH のような環境変数は、信頼できるシステムディレクトリのみを指すよう整理すべきである
  • 現時点では、Screen 5.0.0 だけでなく以前の 4.9 系も setuid-root でインストールしないことが推奨される
  • 代替案として、マルチユーザー機能を opt-in 方式で提供し、信頼されたグループメンバーだけがマルチユーザー版 Screen を実行できるようにする方法がある

公開調整プロセスと upstream の状況

  • 2025年2月、Screen upstream に問題を非公開で報告し、協調公開を提案した
  • upstream は公開前のバグ修正のため問題を非公開に保つことに関心を示し、1〜2か月必要だと伝えた
  • 約1か月後、upstream 側の活動とパッチ議論が始まったが、議論は十分に生産的ではなかった
  • 最大 90 日の embargo 期間が近づくまで追加のやり取りはなく、その間に NetBSD などのディストリビューションが Screen 5.0.0 へ更新し、CVE-2025-23395 の全面的な影響を受ける状態になった
  • upstream が Screen コードベースに十分習熟しておらず、報告されたセキュリティ問題を完全には理解していないと判断された
  • upstream は一部問題が未解決のまま、より早い公開を望み、それに応じて distros メーリングリストへ草案が速やかに送られた
  • その後、SUSE 側が不足していた修正を直接開発し、upstream で草案として議論されていたパッチも調整・文書化した
  • 専任の upstream 体制があれば、協調公開手続きは約 2 週間で完了できたと見られる
  • Screen upstream は人員と専門性の不足に直面しているようで、広く使われるオープンソースユーティリティであることを考えると懸念が大きい

主な日程

  • 2024-07-01: upstream からレビュー依頼が届く
  • 2025-01-08: セキュリティレビュー作業開始
  • 2025-02-07: Screen upstream に非公開報告と協調公開の提案
  • 2025-02-11: GNU Savannah バグトラッカーに非公開バグを作成
  • 2025-04-30: CVE 割り当て決定と distros メーリングリストへの草案共有
  • 2025-05-07: Screen 4.9.1 および 5.0.0 向け完成パッチを distros メーリングリストと upstream に共有
  • 2025-05-12: レポートがブログと oss-security メーリングリストで公開された

関連記事

1件のコメント

 
GN⁺ 2025-05-14
Hacker News のコメント

  • Screen にこういうマルチユーザーモードがあるとは知らなかったが、tmate のようなツールが可能になる理由はおそらくこの機能なのだろう
    適切な認証情報があれば、別のユーザーが所有する Screen セッションにアタッチでき、この機能は Screen が setuid-root としてインストールされている場合にのみ可能だという
    なので tmux も同種の脆弱性の影響を受けるのか気になった

    • tmux は Unix ドメインソケットを使うので該当しない
      screen がなぜここで setuid 方式を選んだのかは分からないし、root 権限はまったく必要なさそうに見える
      記事の後半を見ると、現在の screen 開発者たちがコードベースに完全には慣れていないというもっともらしい説明が出てくるが、だとすれば機能を動かすための一番簡単な方法が setuid-root だった可能性がある
    • かなり優れた機能ではある
      教育セッションで、学生ごとに自分のノートPCへのログインアカウントを用意し、SSH シェルを screen -x に制限したうえで、screen のアクセス制御リストで各学生が自分のウィンドウだけを使えるようにしたことがある
      実習中は、私が screen の所有者として各学生の画面をプロジェクターに映し、クラス全体で結果を見られるようにできた
      セキュリティホールが多いと言われても驚きはしない
    • そう、screen -x

  • Debian では GNU screen は setuid-root 権限ではインストールされない

    • Debian Stable、つまり bookworm のパッケージは古すぎるため、5.0.0 の脆弱性の影響を受けない
      以前は Debian のソフトウェアバージョンがいつも遅れているのが嫌だったが、今ではブラウザーのように本当に古いソフトウェアに依存したくない一部のアプリだけ別のパッケージソースを使い、それ以外は古いパッケージで問題なく過ごしている
    • Slackware 15 では /usr/bin/screen が screen-4.9.0 を指しており、実行ファイルも suid ではない
    • Gentoo も同様
      ただし Gentoo では utmp グループに対して SETGID が付いているが、その影響が何なのかはよく分からない
    • Fedora では setuid-root のようだ

  • レンダリングされたブログ記事はこちら: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • GNU Screen の作者に、ファイルロギング機能のドキュメントが不十分だとメールを送ったことがある: http://www.zoobab.com/screenrc
    GNU にはもっと良い課題追跡システムが必要だ

    • Tmux 作者との Q&A があったが、約16年前にもドキュメント不足に不満を述べていた
      https://undeadly.org/cgi?action=article&sid=20090712190402
    • GNU screen のマニュアルに詳しく文書化されている: https://www.gnu.org/software/screen/manual/screen.html#Log
    • 古いプロジェクトのかなり多くには、課題がインデックスされていないメーリングリストの底なしの深みに埋もれてしまう問題がある
      Discord がこうした情報をアクセス不能にしていると批判されるのは妥当だが、一部のプロジェクトがまだ使っている IRC は実質的にその倍はひどい
      こうしたプロジェクトが Gitea、Forgejo、Codeberg、GitLab、GitHub のような場所へ移り、関連する内容を一箇所に集めて発見可能性を確保してほしい

  • Zellij は screen と tmux の現代的な代替としてかなり良く、デフォルトも優れていて、UI も見つけやすいようによく作られている
    ターミナルマルチプレクサは労力に見合う効用が微妙だと感じていた人におすすめ
    https://zellij.dev
    https://github.com/zellij-org/zellij

    • 数年前に使ってみたが、かなり洗練されていた
      ただ tmux と比べて遅延が目立ち、今も tmux を使い続けている
      当時すでに遅延のある接続を使っていたので、自分が少し敏感だった面もある
    • 最後に Zellij を見たときは、マルチプレクサのエコシステムにおける素晴らしい新プロジェクトのように見えたが、純粋なキーボードベースのコピー/ペースト機構をサポートしていなかった
      その機能を非常によく使うので、なければ使えず、追加されるまでは tmux を使うしかない
    • 良いのだが、screen が本当に好きで、コマンドがすでに筋肉の記憶に刻み込まれている
      20年以上使ってきた

  • アップストリームがここに関与していたことに驚いた
    5年ほど前に GNU screen の開発は完全に止まったのだと悲しく結論づけたのだが、まだそうではないのか気になる
    screen には今でも既存の screen にアタッチせずに新しいウィンドウを追加する機能があるのだろうか

    • アップストリームが SUSE チームに調査を依頼した
      開発人員が不足しており、アップストリームには適切に保守する専門性がないのかもしれないように見える
      もし本当なら悲しいことだ。tmux や他の代替があるのは分かっているが、多くの人が Screen を非常に長い間使ってきたし、ツールが徐々に朽ちていくのは残念だ
    • アップストリームとのやり取りが難しく、先方が行ったバグ修正やリリースに関する詳細情報を現在持っていない、とされている
      セキュリティレビューは依頼したものの、連絡を維持し続けるのが難しかったようで、全体の事情はよく分からない
    • 関与といっても、setuid-root で配布したという程度だ
      そう設定したディストリビューションは脆弱で、そうでないディストリビューションは脆弱ではない
      ごく浅い関与だと思う。アップストリームが遅すぎればディストリビューションがパッチを当てる
    • GNU ツールの開発が止まることは、必ずしも悲しいことではない。もちろんバグ修正は別だが
      基本的には完成されたツールであるというサインとして受け取れる
    • オープンソースには、あるソフトウェアが終わり、それを置き換える別のソフトウェアが作られるときに慣性が生じる問題がある
      すぐに移行する動機がない。なぜならそれはアップデートではなく移行だからだ
      逆に、誰かが既存ソフトウェアの商標を買って Audacity のときのようにまったく別物に変えてしまうのもよくない
      だから良い解決策はなさそうだ

  • レンダリング版: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • tmux は記憶が正しければ OpenBSD 4.6 から基本システムに入り、監査を受けた、または受け続けてきたツールだ
    もう少し安全な代替を求める人には良い

    • screen がまた目に入るのを見ると、かつて tmux に乗り換えたあと screen のことを忘れていた時期を思い出す

  • 観察された挙動は少なくとも2005年以降の Screen バージョンにあり、そのくらい昔からアンチパターンで、rkhunter のようなツールも扱ってきた
    それでも screen は90年代にも setuid root だったと思う

  • 最も人気のあるオープンソースツールは、実際には何人の開発者で運営されているのか？
    そのツールを使っている産業には、どれほどのお金があるのか？