ssh-keysign-pwn - Linux 0-dayで非特権ユーザーがroot所有ファイルを読み取るPoC

 (github.com/0xdeadbeefnetwork)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • ssh-keysign-pwn は、非特権ユーザーが root 所有ファイルを読み取れるようにする Linux 脆弱性の PoC で、31e62c2ebbfd より前のカーネルが対象だとされている
  • 中核となるバグは、__ptrace_may_access() が task->mm == NULL のときに dumpable チェック をスキップし、do_exit() が exit_files() より先に exit_mm() を実行することで、ファイルディスクリプタが開いたまま残る窓が生まれる構造にある
  • この窓の間に、呼び出し元の uid が対象プロセスと一致していれば pidfd_getfd(2) が成功し、終了中のプロセスが開いているファイルディスクリプタを取得できる
  • sshkeysign_pwn は /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key を取得し、ssh-keysign.c が 0600 権限の鍵を開いた後、permanently_set_uid() の前に EnableSSHKeysign=no で終了して、開いた fd を残す流れを利用する
  • chage_pwn は /etc/shadow を取得し、chage -l <user> が spw_open(O_RDONLY) の後に setreuid(ruid, ruid) で権限を完全に落とす流れで、終了レースを狙う
  • 実行は make の後に ./sshkeysign_pwn でホスト鍵を、./chage_pwn root で /etc/shadow の内容を標準出力に出力する方式で、100〜2000 回の spawn のうちに成功するとしている
  • 確認済みの環境は Raspberry Pi OS Bookworm 6.12.75、Debian 13、Ubuntu 22.04 / 24.04 / 26.04、Arch、CentOS 9
  • 制御された対象 PoC として、vuln_target.c は /etc/shadow を開いた後に権限を落とし、exploit_vuln_target.c は生存中の EPERM と SIGKILL 後の fd 奪取を示す
  • 脆弱性は Qualys が報告し、Linus が 2026-05-14 に修正した。また Jann Horn は 2020 年 10 月に FD 奪取の形態 を指摘していたとされる
  • README は NVD 項目として https://nvd.nist.gov/vuln/detail/CVE-2026-46333 を示している

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rsの意見

  • ptraceを無効化するだけでは不十分。コミットメッセージと関数名のせいで誤解しやすいが、ptrace_may_accessは複数の経路から呼ばれており、この概念実証(PoC)も実際にはptraceを使っていない
    緩和策はこれといってなく、現時点では 1) この特定のPoCにだけ弱く対処するために /usr/lib64/misc/ssh-keysign の実行ビットをすべて外す、または 2) eBPF や systemtap などで pidfd_getfd をブロックする、といった程度に見える。前者はカーネルのパッチ適用や停止ができず、とにかく今すぐ寝なければならないときにだけ検討するレベル
    PoCは確認しておらず、ネット上で入手した任意のPoCの実行には、いつものことだが注意が必要
    Qualysのアドバイザリはまだ公開されておらず、Linuxカーネルのセキュリティポリシーのため、linux-distros への配布をやむなく中止すると述べていた。怪しげな修正コミットからPoCまでLLMが素早く作れるようになり、状況は荒れてきており、以前なら数日待つこともできただろう
    Qualysは本当に優れたチームだが、今回の件を自ら適切に発表する機会を持てなかったのは残念。公開されれば、間違いなく優れたアドバイザリになると思う
    openssh はこの攻撃にとって都合のよい標的にすぎず、悪いのはそこではない。他の setuid バイナリも標的に選べるはず

    • Qualysの更新によると、/proc/sys/kernel/yama/ptrace_scope を 2(admin-only attach) または 3(no attach) に設定すれば、既知のすべてのエクスプロイトを防げるという。ただし理論上は別の悪用手法があり得る
    • 応急的な緩和策として、LLMの Opus に pidfd_getfd を止める systemtap スクリプトを書かせたところ、結果は ここ にある。stap -g block_pidfd_getfd.stp で実行する必要があり、ネットで入手したものは何でもそうだが、実行前に必ずスクリプトを確認すべき
    • linux-distros の告知へのリンクはある？ 見つけられない

  • カーネルがメインブランチに修正を公開コミットすることで、自ら 0-dayを公開してしまうのはやめてほしい。コミット に "Reported-by: Qualys" とまで書かれているので、明らかなセキュリティ修正だ

    • 先週、この件について大きな議論があった
      Greg K-Hは、カーネルセキュリティチームはセキュリティ修正の事前公開先を選べないため、結果として誰も事前公開を受けられないのだと書いていた
    • では代わりにどうすべきなのか？

  • これは ssh の問題ではなく Linux の問題だ。タイトルもそう見えるべき

    • タイトルが誤解を招くという点には同意するが、どう付ければよいか他の案が思いつかなかった。まだ修正できるので、提案があればうれしい
    • その通りだが、同時に ssh-keysign が秘密ホストキーを開く前に EnableSSHKeysign=yes を先に確認していれば、デフォルトのようにこのオプションが無効なシステムは ホストキー窃取 に対して脆弱ではなかったはずだ。ssh-keysign が最初にこのオプションを確認しないのは驚き

  • 概念実証が気持ちいいほど短く、私の環境でも実際に脆弱だった
    特定の条件下で、setuid 実行ファイルが開いた ファイルディスクリプタ にアクセスできるようにするものらしい。これが読み取りだけに限られる理由は見当たらず、ハッシュをクラックしなくても済む ローカル権限昇格(LPE) にひねることができそうだ
    このPoCだけなら、chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage で壊せる。ssh-keysign のパスは変更が必要かもしれず、マニュアルページも参照できる。ただし根本原因は直らず、回避も可能そうだ。私の知る限り他の緩和策はない
    この問題は ptrace: slightly saner 'get_dumpable()' logic で修正され、だから公開されてしまった。わずか10時間前のことだ
    oss-security に送られた Qualys の公開告知もある。ディストリビューションとユーザーにパッチを当てる時間を与えるため、まだアドバイザリは公開しないとのこと。かなり興味深い内容になりそうで、それまでは grsecurity の Brad Spengler による解説 を見るとよい。このツイートが今回のPoC開発のきっかけになったようだ

    • PoCを実行してみたが、レースには勝てなかった。その代わり exploit_vuln_target/vuln_target の組はちゃんと動いた。あまりよくない

  • 現実的には、すでに 非特権アカウント を持つユーザーがいるシステムに影響するように見える。つまり、有効なログインがなければ、SSH がインターネットに公開されているサーバーでも、これだけで直接リモートコード実行を達成できるわけではない、という理解で合っている？