GNU Screenに複数のセキュリティ問題が見つかる
引用元：https://news.ycombinator.com/item?id=43971716
記事良いねー＞ screenのマルチユーザーモードって知らなかったんだけど，tmateみたいなのができるのはこれのおかげなのかな．そういえばtmuxも同じ脆弱性の影響あるのかなって思うな．
いや，tmuxはunix domain socket使ってるよ．なんでscreenがsetuidなんて方法選んだのか分かんないな； root権限なんて全然いらない気がするけど．追記：記事をさらに読むと，開発チームがコード詳しくないから，その代わりにsetuid-rootが一番楽だったのかもって説明があったよ．
screenにはさ，1987年の最初のバージョンから引き継がれてる古い設計のクセがたくさんあるんだよね．set-UIDもその一つだよ．当時のドキュメントここに貼っとくね： https：//sources．vsta．org/comp．sources．unix/volume10/screen/
個人的にはさ，screenって10年以上前からほぼ終わってる感じだったんだよね（！）．tmux出てきてからそっちに乗り換えて，全然screen使ってないし，周りにも結構そういう人いるよ．
同じようなことがzellijとtmuxの間でも起きてるんだよね．zellijに乗り換えてから，tmuxが古いって感じるようになったよ．
screenの主な使い方ってリモートでemacs開くことなんだよね．tmuxの主な使い方ってunix IDEのつなぎ役って感じかな．この二つは全然違う使い方で，ツールもそれぞれに特化してるんだ．
色々試してるんだけどさ，tmuxのキーバインド全然覚えられないんだよね．もうGNU Screenのキーバインドが頭に染みつきすぎちゃって．
問題なのは screen -x … の使い方そのものじゃなくてさ， ls -l ”$(which screen) ” の結果が -rwsr-xr-x 1 root root … /usr/bin/screen みたいになってる場合なんだよね．これの4番目の s がsetuidビットが付いてる証拠で，つまりscreenがroot権限で動くってこと．
それが screen がroot権限で動くって意味なんだ．
俺はsetuidのことよく知ってるよ。親コメントには実際の機能に使う引数を教えてあげてただけだよ。
Zellijは使ったことなかったけど、試してみたよ。見た目はtmuxよりいい感じだし、tmuxとキーバインドが似てるから乗り換えもスムーズだった。だけど、バイナリがめっちゃデカいんだよね。zellijがスタティックリンクなのはわかるけど、tmuxは900KiBくらいで依存も少ないのに。strippedしてもターミナルマルチプレクサが38MiBもあるなんて信じられないよ。
最初の投稿者がそれを知らなかったって聞いて驚いたよ。俺がscreenを使うことになった最初の理由（リモートデバッグセッションの共有）だったのにさ。
長時間実行するジョブでは、システムからログアウトするとジョブの出力が止まっちゃうから、その状況を見たいってことがよくあるんだよね。
それ（Zellij）はtmuxより何がいいの？それともfishとzshみたいな感じ？どっちも古いわけじゃないけど、ターゲットユーザーが全然違うみたいな。
あとは、SSHでシステムアップグレードしてる時みたいに、ターミナルセッションが切れるリスクを負えない場合とかね。
確かにね、でもzellijは機能も多いし、一回起動したらそのまま使い続けるものだからバイナリサイズはまあいいんじゃない？単位を調整しないとね。MacでEmacsが350MBもRAM使ってるのを見て驚いたけど、マシンのRAMから見ればほんの少しだし、それより他のリソースで楽しいことしたいって思うよ。
いくつか要因があるよ。プロジェクトの歴史が複雑で、開発者が何度も入れ替わってる。今screenの内部を学ぶのは、OSの歴史や移植性の問題があって昔よりずっと大変になった。擬似端末の動作やセキュリティ問題の対処もOSによってばらつきがある。screenは1980年代の考え方に縛られてる部分が多いんだ。例えばTERMCAPとかね。セキュリティに対する考え方も変わって、記事にあるセキュリティホールも昔は便利な機能だったりしたんだよ。
フラッシュが128MiBしかない組み込みデバイスをいくつか持ってるんだけど、tmuxはちゃんと動くよ。もちろん、この目的でzellijなんて考えもしないけどね。そこにtmuxが入ってるのは「開発目的には良いものだね」って感じ。メモリ使用量に関しては、Zellijは63MiBくらい使うみたいだけど、tmuxは3.8MiBだよ。良いんだけど、かなりメモリ食いだね。これはLinuxでの話で、Macだと違うかもね。
システムアップグレードでセッション切れるなんてありえないだろ，少なくとも俺が知ってるほとんどの環境ではな．
いや，screenの主な使い道は，場当たり的に適当なスクリプトをデーモン化する方法だろ．
組み込みは全然違うのは確かだね．あんな小さいのにtmuxを入れる余地があるなんて驚きだよ．でもデスクトップシステムなら，俺のMacだとZellijはディスク28MB，RAM40MBしか食わないんだ．これは利用可能なディスクの3万7000分の1，RAMの1600分の1だ．最適化されてて小さいアプリは大好きだけど，これくらいだと俺の注意を引くほどでもないな．
ネストできるようにわざわざキーを変えたらしいけど，プレフィックスキーは意図的に分かりにくくしてあって，再マッピングされる前提だって言ってるぜ，たぶんscreenみたいに^aに．
リスクは，インタラクティブな長時間実行プロセス中に他の何かが接続を切断することだ．nohupを使うか，screenかtmuxみたいなものの中で実行すればいい．
^aはemacsユーザーにとって最悪だよ，だって^aは行頭への移動で，めっちゃ使うんだもん．何年か前に初めてscreenを使い始めたとき，emacswiki（だと思う）でも言及されてて，^pに再マップするのをおすすめしてたんだ．それ以来screenとtmuxで俺はそうしてるよ．（なんか記憶違いかも）
俺のシステムではscreenはsetuid持ってないな．
OpenBSDへの移植のような作業は大変だ．特に今は難しくて，昔（90年代）の方が情報源（Usenetなど）があってやりやすかった．1980年代にscreenを修正したり自分で似たプログラムを書いたりした経験から言ってる．
https://jdebp.uk/FGA/bernstein-on-ttys/
注：Debianでは，GNU screenはsetuid-root権限でインストールされてないよ．
それにDebian Stable（別名 bookworm）に入ってるパッケージは古すぎてバージョン5．0．0の脆弱性には影響されないんだ．昔はDebianがいつもソフトのバージョン遅れてるのが嫌いだったけど，今はどうしても古いのに頼りたくない数少ないアプリ（ブラウザとか）には別のパッケージソース使ってるし，それ以外は古いのでも全然大丈夫だよ :-)
Debian stableのユーザーはheartbleedに全く引っかからなかったんだよね．この氷河みたいなペース，もっと評価されていいと思うよ．
＞ Debian stableのユーザーはheartbleedに全く引っかからなかったんだよね
引っかからなかった？とんでもない，Debianは何年も前にあの手のバグの先駆けだったんだよ！
https://github.com/g0tmi1k/debian-ssh
それにデフォルトのSELinuxの設定もたしか15年くらい壊れてたんだよね．いつも何かしら問題はあるってことさ．
もっとコメントを表示（1）
氷河みたいに遅いベースのOSに，オプションでサンドボックス化されたもっと新しいユーザーランドのパッケージとかランタイムをホストシステムの上に乗せるって構成，Flatpak／Snap／AppImageの夢だったよね？
うん，でもそれには問題もあるよね．サンドボックスアプリが触るデータこそ大事なデータだし．SilverblueシステムでOpenSSLいくつ動いてるかなんて正直分かんないし．Flathubの誰かが保証してるだけのアプリが金融情報盗む可能性もある．でもシステムファイルを消したりはできない．
それ良い視点だね．でも付け加えるなら，君が実行してる別のFlatpakアプリは，君の金融情報にアクセスするのちゃんとサンドボックスされてるかもしれない．それこそがこういうシステムの本当のメリットだよ．
関連：
https://bugzilla.mozilla.org/show_bug.cgi?id=1966096
DebianでFirefoxを使ってる人は手動でアップデートしてね．パッケージリポジトリが落ちてるから．最初’サポート’チケット出したけど見られてないみたい．
Mozillaのリポジトリはパッケージのインストールやアップデートには使えそうだよ。Googleのサーバーっぽいからファイル一覧は見れないけど。apt-getでchangelog見たり、パッケージを再ダウンロードできたりすることは確認したよ。
他の読者のために明確にしとくね。Debianのfirefox-esrパッケージはFirefoxだよ。単にMozillaのExtended Support Release版で、君が使ってるRapid Release版とは違うってだけ。別のプロジェクトや製品じゃないからね。
ちなみに、Slackware 15だとscreenのバージョンは4.9.0で、suidはついてないみたい。
追記ね、Slackware 15はscreenが4.9.1にアップデートされてるよ。このアップデートでセキュリティ問題が直ったんだ。具体的には、PTYの一時的な0666モードを防いだり、ファイル存在テストの情報漏洩を防いだり、root権限でシグナルを送らないようにしたりね。
Gentooでも同じだよ。でもGentooだとutmpグループに対してSETGIDが付いてるんだ。これってどういう意味があるのかよく分かんないけど。
utmpグループにいると、ログイン情報データベースをいじれちゃうんだ。Unixから受け継いだこのシステムは、screenみたいな偽端末を使う非rootプログラムがデータベースに書き込みたいっていうのと、rootだけが管理するっていう元々の設計がうまく合ってないのが問題。Laurent Bercotさんがクライアント・サーバーモデルにして改善したけど、グループ内のクライアントならログイン情報を上書きできるっていう設計上の問題はまだ完全に解決してないよ。
だから、TMPDIRを$HOME/tmpにしたんだ。
名前以外は、TMPDIRとutmpは関係ないよ。
分かってるよ。でも、いくつかの潜在的な競合状態を緩和できるんだ。
Fedoraに入ってるみたいだね。
Fedoraでは、rootじゃなくてsetgid screenになってるよ。
攻撃対象領域を減らすSELinuxポリシーがあるのかな
ほぼ確実にあるよ、Fedoraはベースにある全てのソフトウェアにSELinuxポリシーがあるはずだから。
Archでも同じだよ。
レンダリングされたブログ記事はこちらだよ：https://security.opensuse.org/2025/05/12/screen-security-iss
Screenのログ機能のドキュメント足りない件でさ、作者にメールしたんだ。http://www.zoobab.com/screenrc ってとこ。
GNUってさ、もっとちゃんとした課題追跡システム要るよね：）
Tmuxの作者とのQ＆Aがあったんだけどさ。16年くらい前にドキュメントが足りないって愚痴ってたんだよ。https://undeadly.org/cgi?action=article＆sid=20090712190402
TmuxはずっとOBSDのベースに入ってるし、最初からドキュメントもあるよ。
GNU screenのマニュアルに詳しく載ってるよ。ここね。https://www.gnu.org/software/screen/manual/screen.html#Log
古いプロジェクトの課題追跡システムは、メーリングリストやIRCで情報が埋もれやすいのが問題だよね。Discordもそうだけど、IRCはもっとひどい。
GiteaとかForgejoとかCodeberg、GitLab、GitHubみたいな新しいシステムに移行して、情報を一箇所にまとめて、探しやすくしてほしいな。
Zellijってさ、screenやtmuxの代わりに使えるマジでナイスな今どきのやつなんだ。
デフォルト設定もすっごく良いし、UIも分かりやすいようにマジで頑張ってる。
ターミナルマルチプレクサのメリットに対して、覚えるのがめんどくさいなって思ってる人に超おすすめだよ。
https://zellij.dev
https://github.com/zellij‐org/zellij
2年くらい前に試してみたんだけどさ、かなり洗練されてたよ。
でも、レイテンシがtmuxに比べて結構気になったんだ。
当時すでに回線が遅かったこともあって、それに結構敏感なんだよね。だから今もtmux使ってる。
私は個人的には感じなかったんだけどさ、そういうのって人によって感じ方が違うもんね。
最近また試してみた？ 2年前って言ったら、もうすごく前だよ。
まだもっさり感じるのか気になるな。（開発者じゃない、ただのユーザーだけどね。）
最後にZellijを見た時，マルチプレクサのエコシステムでは素晴らしい新しいプロジェクトに見えたんだけど，純粋なキーボード操作でのコピペ機能がサポートされてなかったんだ。俺はそれをめっちゃ使うから，それ無しじゃ無理だった。だからそれが追加されるまでtmuxだな。
うん，俺もいつもあれを使ってるよ。キーボード操作にこだわってターミナルを使ってるから，コピペ機能はマジ必須なんだ。なんでマルチプレクサ作るのにこれが無いのか理解できないね。screenやtmuxみたいにvimショートカットでスクロールバックバッファをナビゲートできるのが超便利で，作業がマジ速くなる。マウスなんて使いたくないんだよ。
それは良いんだけどさ，俺はマジで，マジでscreenが好きなんだ。コマンドが筋肉記憶に焼き付いてるんだよ。20年以上使ってるからね。
もっとコメントを表示（2）
初めてtmuxを試した時，俺も同じ感じだったよ。でも結局，screenのショートカットにめっちゃ近くするようにtmuxを設定したんだ。違うのはいくつかだけだけど，それでtmuxの追加機能やプラグインが使えるようになったんだ。興味あるなら俺の設定ファイル共有できるよ。
今回の件にupstreamが関わってたのは意外だな。5年くらい前，GNU screenの開発は完全に止まったって（悲しい）結論に至ったんだけど，まだそうじゃないのか？
あと，既存のscreenにアタッチしないで新しいウィンドウを追加する機能ってscreenにあるんだっけ？
オープンソースって，あるソフトが終わってそれを置き換える別のソフトが作られる時に，乗り換える即座のインセンティブがないっていう慣性の問題があるよね。アップデートじゃなくてスイッチだからさ。一方で，Audacityみたいに既存ソフトの商標を誰かが買って全く別のものに置き換えちゃうのも悪い。だから良い解決策って無いんだよな。
これってdistroの役目じゃないの？例えばDebianがscreenをtmuxに置き換えることを決めて，もしかしたらscreenと同じコマンドライン引数を受け付けるけど内部的にはtmuxを使うみたいな互換性パッケージを出すとか。（俺はscreenをほとんど使ったことないしtmuxも使ったことないから，この文脈でこれが意味をなすかは分からないけど。)
upstreamがSUSEチームに見てもらうよう依頼したらしい。開発は人員不足で，upstreamには適切にメンテする専門知識がないのかもしれない。もしそれが本当なら悲しいね―tmuxとか他のがあるのは知ってるけど，たくさんの人が何年もScreenを使ってきたんだから。ツールがbitrotするのは最悪だよ。
どう見てもtech-debtまみれの巨大なソフトで，新しい開発者には理解できないみたいだね。もしそうなら，”人員不足”じゃなくて，置き換えられるか書き直されるまで腐っていく運命なんだよ。良いニュースは，ほぼ完璧な代替品がそこら中にあって，しかもほとんどがもっとスリムってことだな。
Tmuxはシリアルポートに対応してないよ。
screenのカジュアルユーザーなんだけど、代わりにどんなツールを見ればいいの？
screenより良いのが欲しいならtmux。
概念を見直したのが欲しいならzellij。
俺は後者の方が好きだな。自分の考え方と合ってるし、多くの人が乗り換えて良かったって言ってるよ。前者（tmux）を毎日使ってる人も多いけどね。
tmuxは素晴らしいけど、screenの9割の使い道”切断したりログアウトしてもプロセスを動かし続けたい”には高機能すぎるんだよね。
moshもうまくいったことがあるけど、これもなんか停滞してるみたい。
https://mosh.org
俺の使い道にはこれで十分だけどね。
GNUツールの開発が止まるのが必ずしも悲しいわけじゃないよ（バグ修正以外はね）。それは基本的に完成してるってことの表れだと思うんだ。
なんで”screen”が2つの別々の機能を統合したのかよく分かんないんだよね。シリアルポートアクセスには”tio”みたいなもっとミニマルなものを使えるし、そっちの方がずっとエレガントだよ。
setuid-rootで配布してる限りは関与してるってこと。
そう設定してるDistrosは脆弱だけど、そうじゃないのは大丈夫。
ほとんど関与してないって言えるかな。’
upstreamが遅すぎたらDistrosがパッチ当てるしね。
シリアルポートって何？何に使うの？
TFA（記事）によると、upstreamがレビューを求めたって書いてあるよ。
普通、ああいう風にツールを別のものに透過的に置き換えることはできないよ。互換性がない例を他のコメントでみんな挙げてくれてるし。
もしDistrosがこっそり置き換えようとしたら、ユーザーの間で大騒ぎになるだろうね。
せいぜい、それを望む人向けに”tmux-as-screen”みたいなパッケージを提供できるくらいじゃない？
