脆弱性修正 on KnightLiブログ

ssh-keysign-pwn（CVE-2026-46333）解説：Linux のローカル情報漏えい、SSH ホスト鍵、/etc/shadow のリスク

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn は、Linux kernel の __ptrace_may_access() のロジック問題をめぐって公開された一連の利用経路で、CVE 番号は CVE-2026-46333 です。リモートから未認証で悪用できる脆弱性ではなく、直接 root shell を得るものでもありません。それでもリスクは高く、ローカルの低権限ユーザーが、本来アクセスできない root 所有の機密ファイル、たとえば SSH ホスト秘密鍵や /etc/shadow を読み取れる可能性があります。

運用上の重点は PoC の再現ではありません。影響を受けるマシンを特定し、カーネルを更新し、再起動して修正済みカーネルで起動し、必要に応じて SSH host keys のローテーションやパスワードリセットを行うことです。

まず結論

この脆弱性は高い優先度で対応すべきです。理由は次の 4 つです。

root 権限は不要で、ローカルの低権限ユーザーから発火できます。
公開 PoC が存在し、悪用のハードルが下がっています。
対象は通常ファイルではなく、SSH ホスト秘密鍵や /etc/shadow になり得ます。
修正にはカーネルパッチと再起動が必要で、パッケージ更新だけでは不十分です。

複数ユーザー、ローカル shell、共有ホスト、CI runner、コンテナホスト、学生用端末、踏み台サーバー、または完全には信頼できないローカルユーザーがいるサーバーでは、優先的に対応してください。

脆弱性の概要

Qualys は 2026 年 5 月 15 日、oss-security でこの問題を公開しました。Qualys はそれ以前に Linux kernel の __ptrace_may_access() ロジック問題を security@kernel.org に報告しており、上流修正は Linus によってマージ済みでした。その後、公開 exploit コードが現れたため、Qualys は情報を oss-security に投稿しました。

その後 Linux kernel CVE チームがこの問題に CVE-2026-46333 を割り当てました。NVD ページではソースが kernel.org とされ、問題説明はカーネルコミット ptrace: slightly saner 'get_dumpable()' logic に対応しています。

簡単に言えば、この脆弱性はプロセス終了経路にあります。一部の特権プロセスが終了中の場合、対象タスクがすでに mm を持たないため、カーネル内の ptrace アクセスチェック関連ロジックが、本来依存すべき dumpable チェックを迂回してしまう可能性があります。攻撃者は非常に狭い競合ウィンドウで、終了中の特権プロセスがまだ開いているファイルディスクリプタを取得できます。

これが ssh-keysign-pwn と呼ばれる理由です。公開された利用経路の一つは ssh-keysign を使い、SSH host private keys を読み取るものです。

SSH ホスト秘密鍵と /etc/shadow が読まれる理由

この問題の本質はローカル情報漏えいです。特権プログラムの終了過程で「メモリ記述子は切り離されたが、ファイルディスクリプタはまだ閉じられていない」時間差を悪用します。

AlmaLinux のアドバイザリはリスクを明確に説明しています。特権プログラムが権限を落とす前に機密ファイルを開いており、攻撃者が終了ウィンドウ中に対応するファイルディスクリプタを取得できれば、その機密ファイルを読み取れる可能性があります。

公開議論でよく挙がる対象は次の 2 つです。

ssh-keysign：/etc/ssh/ssh_host_*_key のような SSH ホスト秘密鍵に関係する可能性があります。
chage：/etc/shadow に関係する可能性があります。

SSH ホスト秘密鍵が漏えいすると、攻撃者はそのホストになりすまし、SSH のホスト ID 信頼を損なう可能性があります。/etc/shadow が漏えいすると、攻撃者はパスワードハッシュをオフラインで解析し、後続の侵害を広げることができます。

そのため、これは「直接 root shell」ではなくても高優先度で扱うべき問題です。

影響範囲の判断

上流の観点では、これは Linux kernel の脆弱性です。NVD の記録では、この問題は 2026 年 5 月 15 日に NVD データセットへ追加されており、その時点では CVSS スコアは付与されていませんでした。

ディストリビューションごとの状態は、それぞれのアドバイザリで確認してください。

AlmaLinux 8、9、10 は対応情報を公開し、2026 年 5 月 16 日の更新で patched kernels が本番リポジトリに入ったと説明しています。
Debian Security Tracker は bullseye、bookworm、trixie、sid などの vulnerable/fixed 状態と fixed versions を掲載しています。
その他のディストリビューションでは、Ubuntu、Red Hat、SUSE、Arch、Alpine などの公式セキュリティページや更新リポジトリを確認してください。

カーネルの上流バージョン番号だけで安全かどうかを判断しないでください。ディストリビューションは修正を backport するため、同じ上流バージョンに見えても、配布元によってパッチ状態が異なる場合があります。

優先的に対応すべきマシン

リスク順に対応するなら次の順序を推奨します。

複数ユーザーサーバーと共有ホスト。
通常の shell アカウントがある踏み台、教育用端末、開発機。
CI runner、ビルドマシン、ホスティング基盤ノード。
コンテナホストと仮想化ホスト。特に完全には信頼できない workload が共存する環境。
公開サービス用マシン。脆弱性自体はローカルアクセスを必要としますが、Web/RCE/弱いパスワードで低権限の足場が得られるとリスクが重なります。

純粋な単一ユーザーデスクトップのリスクは相対的に低めですが、システム更新で修正することを推奨します。ブラウザ、開発ツール、スクリプト、サードパーティソフトウェアを通じたローカル低権限コード実行は珍しくないためです。

修正方針

最優先の修正は、ディストリビューションが提供する修正済みカーネルをインストールし、再起動することです。

コマンドはディストリビューションごとに異なりますが、原則は同じです。

パッケージメタデータを更新する。
CVE-2026-46333 修正を含む kernel パッケージをインストールする。
再起動して新しいカーネルで起動する。
uname -r とディストリビューションのセキュリティアドバイザリで、実行中カーネルが修正済みか確認する。

AlmaLinux のアドバイザリでは、本番リポジトリに修正済みカーネルが提供されており、通常の dnf upgrade と再起動で対応できるとされています。Debian tracker も複数ブランチの fixed versions を掲載しています。

注意点として、新しい kernel パッケージをインストールしただけで再起動しない場合、古い脆弱なカーネルがまだ動作しています。

一時的な緩和策：ptrace_scope を厳しくする

すぐに再起動できない場合は、まず Yama の ptrace_scope を厳しくしてください。

Qualys は oss-security の後続返信で、/proc/sys/kernel/yama/ptrace_scope を 2（admin-only attach）または 3（no attach）に設定すると、既知の公開利用経路を阻止できると確認しています。ただし理論上は別の利用方法が存在し得るとも述べており、これは修正ではなく緩和策です。

一時設定は次の通りです。

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

永続化する場合は sysctl 設定に書き込みます。

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 は ptrace attach を無効化するため、gdb や strace -p などのデバッグに影響する可能性があります。本番環境でデバッグが必要なら 2 を検討してください。どちらを選んでも、カーネル更新と再起動は早めに計画すべきです。

SSH ホスト鍵をローテーションすべきか

脆弱性公開前後に次の条件があったマシンでは、保守的に対応することを推奨します。

信頼できないローカルユーザーがいる。
共有ホスト、またはコンテナ/CI のマルチテナント環境である。
Web 脆弱性、弱いパスワード、サプライチェーンスクリプトなど、攻撃者にローカル足場を与え得る要素がある。
ログに不審なローカルプロセス、異常なデバッグ挙動、公開 PoC ファイルがある。
修正前に長時間露出していた。

保守的な対応には次が含まれます。

修正と再起動後に SSH host keys をローテーションする。
既知ホスト指紋管理システムを更新する。
そのホスト指紋に依存する自動化システムへ通知する。
SSH 接続アラートを確認し、正当な指紋変更を中間者攻撃と誤認しないようにしつつ、本当のリスクを見逃さない。

/etc/shadow が漏えいした疑いがある場合は、パスワードリセット、弱いパスワードの禁止、古いハッシュがオフライン解析可能かどうかの確認も検討してください。

監視すべきもの

この種の脆弱性は利用ウィンドウが短く、従来のログに完全には残らない可能性があります。それでも次の点は確認できます。

通常ユーザーディレクトリに ssh-keysign-pwn、chage_pwn、または類似 PoC ファイルがないか。
短時間で見慣れない C プログラムをコンパイルするなどの不審なコンパイル行為。
/etc/ssh/ssh_host_*_key や /etc/shadow への異常アクセスの兆候。
異常な pidfd_getfd、ptrace、デバッガ関連の挙動。
外部システムから SSH ホスト指紋異常が報告されていないか。

これらのシグナルは悪用を証明するものではなく、存在しないからといって悪用されていない証明にもなりません。最優先事項は、パッチ、再起動、認証情報のローテーション、リスク隔離です。

よくある誤解

1 つ目の誤解：これは OpenSSH のリモート脆弱性ではありません。名前に ssh-keysign が入っていますが、根本原因は Linux kernel の ptrace アクセスチェックロジックであり、sshd のリモート認証フローではありません。

2 つ目の誤解：ローカルユーザーがいなければ完全に安全、というわけではありません。確かにローカル実行条件は必要ですが、実際の攻撃チェーンでは Web サービス、CI、スクリプト、弱いパスワード、コンテナエスケープなどを足がかりに低権限のローカル実行を得ることがよくあります。

3 つ目の誤解：ptrace_scope を設定すれば十分、というものです。これは一時的な緩和策であり、根本修正ではありません。カーネル更新と再起動は必要です。

4 つ目の誤解：root を取られていなければ問題ない、というものです。SSH ホスト秘密鍵や /etc/shadow の漏えいだけでも、横展開、ホストなりすまし、オフライン解析につながる十分なリスクがあります。

対応チェックリスト

次の順序で実行することを推奨します。

影響を受ける Linux ホストを棚卸しする。特に複数ユーザー環境と共有環境を優先する。
ディストリビューション公式のセキュリティアドバイザリを確認し、fixed kernel version を特定する。
修正済みカーネルをインストールして再起動する。
すぐに再起動できないマシンでは、先に kernel.yama.ptrace_scope=2 または 3 を設定する。
修正後、実行中のカーネルバージョンを確認する。
高リスクマシンでは SSH host keys をローテーションする。
/etc/shadow 漏えいが疑われる場合、パスワードリセットとアカウント監査を検討する。
公開 PoC、異常なコンパイル、不審なローカルデバッグ挙動を確認する。

まとめ

ssh-keysign-pwn（CVE-2026-46333）は、Linux kernel の __ptrace_may_access() 関連ロジックに起因するローカル情報漏えい脆弱性です。リモートから直接侵入できるものでも、直接 root shell を与えるものでもありませんが、低権限ローカルユーザーが高価値の機密ファイルを読み取れる可能性があるため、複数ユーザー、共有ホスト、CI、コンテナホスト環境では特に警戒が必要です。

最も確実な修正は、ディストリビューション提供の修正済みカーネルへ更新し、再起動することです。ptrace_scope=2/3 は一時的な緩和策として使えますが、パッチの代替にはなりません。リスクウィンドウにさらされていた重要ホストでは、SSH ホスト鍵のローテーションとパスワードリスク評価も検討してください。

参考リンク：

Dirty Frag CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag は、2026 年 5 月に公開され、実際の悪用の兆候も報告されている Linux kernel local privilege escalation 脆弱性群である。Microsoft は、攻撃者がすでに低権限の code execution を得た後に root へ昇格する post-compromise risk として説明している。Ubuntu も CVE-2026-43284 を High として扱っている。

この種の脆弱性で危険なのは、「remote から一発で侵入される」ことではない。「侵入後に権限を一気に広げられる」ことだ。攻撃者が弱い SSH account、WebShell、container escape、低権限 service account、phishing 後の remote access などで local execution を得ると、Dirty Frag を使って root を取得し、security tooling の停止、credential の読み取り、log 改ざん、lateral movement、persistence につなげる可能性がある。

Dirty Frag に関係する CVE

現在の公開情報では、Dirty Frag は主に二つの番号と関係している。

CVE-2026-43284：Linux kernel の xfrm/ESP path に関係する。Microsoft が言及する esp4、esp6 はこのリスク領域に含まれる。
CVE-2026-43500：Microsoft は rxrpc に関連すると説明しているが、2026 年 5 月 8 日時点では NVD にまだ正式公開されておらず、patch status も変化中である。

したがって、実際の確認では一つの CVE だけを見るべきではない。esp4、esp6、rxrpc、関連する xfrm/IPsec 機能が有効か、必要か、distribution kernel patch があるかをまとめて確認するのが安全だ。

技術的な概要

Microsoft と Ubuntu の説明によると、CVE-2026-43284 は Linux kernel の networking と memory-fragment handling、特に ESP/IPsec path における shared page fragments の扱いに関係する。

簡単に言えば、data page は splice などの仕組みで network buffer に attach されることがある。その後の kernel path が、それらの fragment を privately owned data とみなして in-place modification できるものとして扱うと、本来書き込むべきでない場所で in-place decrypt や modification が起きる可能性がある。攻撃者はこれを利用して page cache behavior を操作し、最終的に local privilege escalation を達成し得る。

これは以前公開された CopyFail（CVE-2026-31431）と背景が似ている。どちらも Linux page cache、kernel data path、local privilege escalation を中心にしている。Dirty Frag が危険なのは、追加の attack path を持ち、狭い race window に依存する従来型 LPE より安定しやすい可能性がある点だ。

優先的に見るべき環境

Dirty Frag は local privilege escalation なので、攻撃者がすでに対象 machine 上で code を実行できることが前提になる。優先的に確認すべき環境は次の通り。

SSH を公開している Linux server。
WebShell を書き込まれる可能性がある Web application server。
multi-user login host、bastion、developer machine、CI/CD runner。
container host、Kubernetes node、OpenShift node。
IPsec、VPN、xfrm、RxRPC 関連機能を使う system。
Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE など主要 distribution を動かす server。

local multi-user、container、露出した application path がまったくない server ではリスクは低めだ。しかし「攻撃者が low-privileged shell を得る可能性」がある system では、高優先度の kernel vulnerability として扱うべきである。

まず patch を優先する

最も確実な修正は、distribution が提供する kernel security update をインストールし、新しい kernel で reboot することだ。

Ubuntu の CVE page では、CVE-2026-43284 は 2026 年 5 月 8 日に公開され、priority は High とされている。Microsoft も Linux Kernel Organization が CVE-2026-43284 の修正を公開しており、できるだけ早く patch を適用するよう促している。

まず system を確認する。

1
2

uname -a
cat /etc/os-release

distribution に合わせて kernel を更新する。

`1`	`sudo apt update && sudo apt full-upgrade`

または：

`1`	`sudo dnf update`

更新後は、新しい kernel で起動していることを必ず確認する。

`1`	`uname -r`

kernel package をインストールしただけで reboot していない場合、古い kernel が動き続けるため、脆弱性は残る可能性がある。

暫定緩和：関連 module を無効化する

patch がまだない、または production をすぐ reboot できない場合は、関連 module を一時的に無効化できるか評価する。Ubuntu の緩和策は、esp4、esp6、rxrpc の loading を block し、すでに loaded なら unload するというものだ。

modprobe block rule を作成する。

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

early boot で module が load されないよう initramfs を更新する。

`1`	`sudo update-initramfs -u -k all`

すでに loaded な module を unload する。

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

module がまだ loaded か確認する。

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

module が業務で使われている場合、unload に失敗することがある。その場合、block rule は reboot 後に有効になる可能性が高い。

無効化前に業務影響を確認する

上の緩和コマンドをそのまま貼り付けてはいけない。esp4、esp6、xfrm/IPsec 関連機能は、VPN、tunnel、encrypted networking、Kubernetes/container networking、企業 network configuration で使われている可能性がある。rxrpc も、その protocol に依存する workload に影響する。

production で実行する前に、少なくとも次を確認する。

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

IPsec VPN や関連 kernel networking に依存している場合、module 無効化で接続が切れる可能性がある。その場合は、module block に長く頼るより、kernel patch と maintenance reboot を早めに計画するべきだ。

侵害後確認を省かない

Microsoft は、緩和策だけでは成功した exploit による変更を元に戻せない可能性があると強調している。攻撃者がすでに root を得ていた場合、persistence、file modification、log tampering、session data access が残っている可能性がある。

少なくとも次を確認する。

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

特に次を見る。

異常な su、sudo、SUID/SGID process launch。
最近追加された ELF executable。
Web directory 内の怪しい PHP、JSP、ASP file。
SSH authorized_keys の変更。
systemd service、cron、rc.local に追加された persistence。
container host 上の異常な privileged container や mount。

悪用が疑われる場合は、host を isolate し、evidence を保存し、credential を rotate してから cleanup する。module unload や cache clearing だけで安全になったと考えてはいけない。

drop_caches について

Microsoft は、一部の post-exploitation integrity verification で cache clearing を検討できると述べている。

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

これは vulnerability fix でも incident cleanup command でもない。cache clearing は追加の disk I/O と production performance への影響を起こし得る。影響を理解したうえで補助操作として使うべきだ。本当の修正は patch、reboot、integrity verification、persistence check である。

推奨対応順序

production environment では、次の順序が比較的安全だ。

Linux asset と kernel version を棚卸しする。
exposed SSH、Web workload、container host、multi-user system を優先する。
reboot できる system は早急に patch して新 kernel で起動する。
まだ patch または reboot できない system は、esp4、esp6、rxrpc の無効化を評価する。
su、SUID/SGID、異常 ELF、WebShell、container escape indicator の監視を強化する。
悪用が疑われる host では侵害後確認と credential rotation を行う。

まとめ

Dirty Frag は「remote one-click」脆弱性ではないが、侵害後のリスクを大きく高める。攻撃者が local で低権限 code execution を得るだけで、CVE-2026-43284 と関連する rxrpc attack surface を使って root へ昇格できる可能性がある。

管理者にとって重要なのは PoC 研究ではない。kernel が影響を受けるかを確認し、distribution security update をインストールして reboot すること。patch window 前には関連 module の無効化を評価すること。そして露出している system や疑わしい system では integrity と persistence を確認することだ。

参考リンク：