LinuxのSMB実装でo3を活用してリモート0-dayを発見
(sean.heelan.io)- OpenAI o3モデルを活用して、LinuxカーネルのSMB実装でリモート0-day脆弱性（CVE-2025-37899）を発見した経験を共有する
- ksmbdのコードに対するLLMの分析能力をベンチマークする過程で、既存の手動発見脆弱性を基準としてLLMの性能を比較実験した
- 脆弱性検出の過程では、関数ごとにコンテキストを構成し適切なプロンプトを与えることで、o3が脆弱性を認識できるよう設計した
- 実験の結果、o3は既存LLM比で2〜3倍高い精度で脆弱性を見つけ、新しい形のuse-after-freeバグも同時に自動発見した
- LLM、とくにo3のような最新モデルは、コード監査と脆弱性研究において人間のアプローチに近い柔軟性・創造性を示し、実務での活用価値が高まっている
はじめに
この記事では、OpenAIのo3モデルを使ってLinuxカーネルのSMB実装（ksmbd）でリモート0-day脆弱性をどのように発見したかを紹介する。単にo3 APIだけを利用し、別途フレームワークやツールなしで実験を進めた。ksmbdはLinuxカーネル内でSMB3プロトコルを実装し、ネットワークファイル共有を担うサーバーである。LLM関連開発から少し離れようとして始めた脆弱性監査をきっかけに、o3が実際のバグをどれほどうまく見つけられるかをベンチマークした。ここでは特に、o3が見つけたゼロデイ脆弱性であるCVE-2025-37899に焦点を当てる。
この脆弱性は、SMBのlogoffコマンドの処理過程で発生するuse-after-freeの問題である。これはサーバーに対する同時接続の状況と、特定オブジェクトを複数スレッドが共有する方式への理解を必要とする。o3はこのような並行性の問題とオブジェクト管理上の誤りを文脈の中で把握し、脆弱性を検出した。これはLLMがこの種の脆弱性を発見した最初の公開事例である。
主なメッセージは、o3によってLLMのコード分析および論理能力が一段階飛躍したことを示しており、脆弱性研究者なら必ずこの流れに注目すべきだという点である。LLMが専門家を置き換えるわけではないが、すでに専門家の生産性と効率を飛躍的に高めるツールへと発展していることを示唆している。1万行以下のコードであれば、o3によって大半の問題の検出と解決に実質的な助けを得られる。
CVE-2025-37778を用いたo3のベンチマーク
ベンチマークの背景と趣旨
まず、自ら手動で発見した脆弱性であるCVE-2025-37778（以下、Kerberos認証脆弱性）を基準点として、o3の脆弱性検出能力を評価した。これはクライアント認証過程で、セッション状態が特定条件を満たすときにuse-after-freeが発生する問題である。
- セッション状態が
SMB2_SESSION_VALIDのとき、ユーザーオブジェクトをメモリから解放 - その後認証が失敗すると、ユーザーオブジェクトが再初期化されないまま、その状態でアクセス可能になってuse-after-freeが発生
- 関連経路全体を把握するには約3,300行のコードを追う必要があり、適度な難易度を持つベンチマーク課題である
分析コンテキストの構成
実験では、実際の自動化された脆弱性検出システムの観点から、LLMに与えるコンテキスト（コード領域）を注意深く構成した。SMBコマンドハンドラ単位で主要関数および下位関数を3段階のコールデプスまで含め、論理的に関連するコードをすべて入力した（合計3.3k LoC、約27kトークン）。データ解析、リクエスト分岐、接続解除などの関連関数も含めてこそ、信頼性の高い結果が得られる。
具体的に使用したプロンプトと入力資料は、関連するGithubリポジトリで確認できる。LLMには以下のような条件を与えた。
- use-after-free脆弱性を検出するよう明確に指示
- ksmbdの基本構造と脅威モデルを簡潔に説明
- 偽陽性（False Positive）を防ぐための誘導プロンプトを使用
実際のクエリはllmコマンドラインツールで繰り返し実行し、実験結果を収集した（N=100）。
ベンチマーク実験の結果
- o3：100回中8回Kerberos認証脆弱性を検出、66回は未検出（見落とし）、28回は偽陽性を報告
- Claude Sonnet 3.7：3回のみ検出
- Claude Sonnet 3.5：100回すべて検出失敗
結果として、o3は既存LLM比で2〜3倍以上高い精度を記録した。また実際のo3の出力は、人間のセキュリティ研究者が書いた要約レポートのように簡潔だった。一方、Sonnet 3.7の結果は過程中心の作業ログに近い印象で、長所も短所も共存している。
o3による実際の0-day（CVE-2025-37899）発見
大規模コード入力環境の実験
Kerberos脆弱性に加えて、SMBコマンドハンドラ全体（約9,000行）を含め、o3で全体的な脆弱性検出も試みた。各種ハンドラ、接続・切断コードなどを合わせて合計約12k LoC（約10万トークン）を一度に入力した。100回の反復実行では、Kerberos認証脆弱性は1回しか検出されず性能低下は明確だったが、主な目的はより広いコード範囲でのLLM活用可能性の実験である。
今回の実験で見つかった新たな脆弱性
その過程で、o3がKerberos認証とは別に新たなuse-after-freeバグを発見した。具体的にはセッションのlogoffハンドラにおいて、2つのスレッドが同時接続状態でセッションのuserオブジェクトを共有・参照する際、一方のスレッドがオブジェクトを解放した後でも、もう一方のスレッドがそれを参照し続けられるという並行性の問題である。
o3の脆弱性自動レポート要約
- 2つのワーカースレッドが協調し、一方はセッション解放（logoff）実行中にuserオブジェクトをメモリから解放し、もう一方は既存セッションでそのuserオブジェクトを使い続ける
- 解放直後（まだNULLに初期化される前）に別の経路でdereferenceが発生すると、典型的なuse-after-freeとなる
- タイミング次第では、NULL dereferenceによるDoSも発生しうる
- カーネルメモリ破壊や任意コード実行につながる可能性がある
自動レポートから得られた知見
この自動レポートにより、既存のKerberos認証脆弱性の修正方式（解放直後にNULLを設定すること）が、logoff処理では根本的な解決策ではないと気づいた。つまり、セッションバインディングとスレッド間の攻撃ベクターを考慮してこそ安全性が保証される。o3も一部のレポートではこの点を見抜き、より強力な修正策を提示できることを実証した。
結論
LLM、とくにo3のような最新モデルは、コードの創造的・柔軟な分析という面で既存手法より人間のセキュリティ研究者にはるかに近い性能を示す。最近まで理論的な可能性として語られてきたが、実例において現実的に「役に立つ水準」に到達したのはo3が初めてである。もちろんo3にも依然として誤検出や見落としの可能性はあるが、実際に有用な結果を出せる可能性が高まり、実務投入が意味を持つ段階に入った。今や脆弱性研究者や開発者は、自らの業務フローにLLMを効率よく組み込む方法を見つけるべきタイミングである.
1件のコメント
Hacker Newsのコメント
著者は、システムプロンプト、背景情報、補助コマンドなどをそれぞれ別個の
.promptファイルとして構成し、それをllmで実行する方式でプロジェクトを管理していると明かしていた。このように体系立てて LLM を活用するやり方は、まるで他のエンジニアリングツールのように、緻密な設計思考と細やかな仕様のバランス調整を必要とするものだと感じた。
関連プロジェクトは こちら で確認できる。
興味深いことに、著者がその部分について「実のところ、自分のシステムプロンプト全体は推測に基づいていて、科学やエンジニアリングとはほど遠い」と率直に述べていた点が面白く感じられた。
さまざまなプロンプト作成法はあるものの、実際に評価したり比較したりする適切な基準がなく、まるで即興の呪文を唱えているようだと思う。
たとえば「あなたは脆弱性発見の専門家だ」「偽物ではない本物の脆弱性だけを教えてくれ」といった指示や、モデルがよく反応すると推測される任意の HTML タグで区切ることなどだ。
エンジニアリング的な要素が実際にどこに入ってくるのか疑問だ。
本質的に不安定で予測不能なシステムを制御しようとする際に、エンジニアリング原則を持ち込むのは面白く感じる。
こうしたプロンプトは、むしろ「ヒント」と呼ぶほうが適切だ。
最近のあらゆる LLM は、たとえプロンプトが矛盾していても、回答を（それが真実かどうかに関係なく）必ず返そうとする本質的な目標のもとで、プロンプトを無視することが多い。
該当記事では信号対雑音比がおよそ 1:50 だと言及されていたが、著者はコードベースをよく理解しているため、有意味な信号をうまく選び出せたのだと思う。
この点、つまり意味のある信号の判別を自動化することこそ、実際に LLM 活用で得られる大きな価値だと見ているので、今後の動向を注意深く追いたい。
私たちはこの信号対雑音比の問題を改善するシステムを開発中で、最近人気のあるソフトウェアエージェントも自分たちでベンチマークしている。
結果のばらつきは非常に大きく、近いうちに開催されるカンファレンスですべての実験結果を公開する予定だ。
業界の最新動向を一望できるはずだ。
数日前に思いついたのだが、すべての git の変更履歴やメーリングリストなど、Linux カーネルに存在した歴史を活用して fine-tune モデルに発展させることはできないだろうか。
そういう LLM であれば、実際に長年コードを扱ってきた開発者の感覚により近い、合成的なバージョンになり得るのではないかと期待している。
長大なコンテキストだけでもかなりカバーできるし、いくつかのコードベースはコードそのものだけで 20 万トークンを超えることもあるので、可能性はあると思う。
1:50 という比率は、「干し草の山から針を探す」ような状況では非常に優れた検出率だ。
もし LLM が各脆弱性の推定を裏づけるハーネスや概念実証テストまで自動で書けるなら、信号対雑音比は大幅に改善するはずだ。
ただし現時点では、そうした自動化はコストがかなり高いのが惜しい。
著者本人が、複数の LLM モデルごとに脆弱性検索を 100 回も繰り返したという事実が最も印象的だった。
これほどのリソース投入は、これまで私が LLM で扱ってきたほとんどの問題と比べてもかなり大きい部類で、私もそろそろモデルに一度「脳死反復」を任せてみようかと考えている。
結局は金がかなり必要だという結論になる。
ゼロデイ脆弱性はかなりの金額で売れるし、バグバウンティでも収益を得られる。
LLM の利用コストは、こうした報酬と比べればごくわずかだ。
推論コストがほぼゼロに近づいた未来のセキュリティ環境は、まったく違う姿になるだろう。
モデルごとに 100 回実行するというのは、エネルギー消費も相当大きいということだ。
C ベースのコードでよくある脆弱性を 1 つ見つけるために、ここまでリソースを費やしているとなると、その意味は薄れ、むしろ浪費と贅沢の証拠ばかりが目立つ気がする。
今は地球規模の気候危機のただ中にあることを思うと、1950 年代のように大して価値のないことへ資源を燃やし続ける姿勢がどうにも気がかりだ。
Claude では scratchpad（中間的な思考の整理スペース）が別途与えられていなかったため、成果物に思考の流れとレポートが混ざっていたのだと思う。
公式に思考を整理するための空間が許可されたとき、Claude がどれほど変わるのか試してみたい。
o3 が人間の書いたバグレポートのように要点だけを洗練して伝える一方で、Sonnet 3.7 の結果には頭の中の思考や作業ログのような流れが残っているのも、同じ文脈だろう。
実際に o3 と 3.7、Gemini 2.5 pro をすべて使ってみたが、o3 は比較にならないレベルという印象だった。
ベンチマークスコアはそこまで大きく見えないかもしれないが、複雑な作業になるほどこの差の意味は大きくなる。
昨年 11 月に発表だけしておいて、実際のリリースがつい 1 か月前だった理由が気になる（たぶん安全性確保のためではないかと思う）。o4 も早く見たい。
「scratchpad」を研究に活用した事例や論文、関連リンクをおすすめしてもらえないだろうか。
prompt engineering の本質をあまりに的確に要約した部分が気に入った。
特に「偽陽性で誤った脆弱性が表示されないよう最善を尽くしてガイドしたが、実際にこれが役立っているのか私には知る術がなく、ただ役立っていてほしいと願うばかりだ。まだこれが有効か十分に評価できていないので、科学でも工学でもない。評価は後ほど共有する」という部分は、自分のプロンプト開発の流れとあまりにも似ている。
LLM に最も適した活用例は、こうした（自動脆弱性検出）分野なのではないかと思う。
理論上はプロセス全体を自動化し、LLM を非常に高度なファザーのように扱ってターゲットを VM 上でひたすら実行し、異常が検知されたら本物の脆弱性の可能性を見つけられる。
（初期段階のエクスプロイトの多くは、まずマシンを落としたりクラッシュを引き起こしたりするところから改善されていくことを思い出してほしい。）
この種の LLM 活用は、一方では非常に有効に見えるが、他方で「こうしたテストができるからといって、特別に新しいことや決定的な何かが明らかになったわけではない」という示唆も伴う。
zk バグ（ゼロ知識証明関連）の自動ターゲティングをテーマに、自分が発表した資料として YouTube リンク を残しておく。
追加パラメータはリンク追跡用のものと理解している。
curl で繰り返し起きている問題のようにならないことを心から願う。
関連する文脈は Daniel Stenberg の記事 を参照。
私の知る限り、ksmbd は従来の Samba サーバーより軽量で高性能を志向する、カーネル空間の SMB サーバーとして知られている。
Q1: 実際に ksmbd を本番環境で使っているのは誰なのだろうか。
Q2: 使う理由は何だろうか。
これが Windows のように ACL をネイティブにサポートしているか知っている人はいるだろうか。
（これが Solaris を使い続ける最後の理由だったが、ZFS を通じてサポートされていると理解している。）
Samba は今なお Unix の UID/GID とセキュリティモデルの同期に縛られているなど、時代遅れの構造だ。
カーネル内 SMB サーバーでは、Windows で深刻なリモート root 脆弱性が実際に発生したこともあり、トレードオフは明確にすべきだ。
ライセンス問題が原因だ。
Samba は GPLv3 だが、Linux は GPLv2 しか使えない。
単に軽量で高性能だから使われているのだと推測する。
relayd の代わりに kmod-trelay を使うのと似た理由だと思う。
LLM の短期的な最大の難題（Alignment Problem）は、むしろこうした脆弱性自動化で表れるのではないかと思う。
最近、自分がたまに使うニッチなサーバーで、本当に深刻なセキュリティ脆弱性を LLM によってほとんど労力なく発見した。
この市場が自動化されれば、以前なら手作業で破る価値がなかったような、ありとあらゆるロングテールのソフトウェアで深刻な問題が大量に噴き出すのではないかと心配している。
逆に、こうした技術の進歩によって、私たち自身も自分たちのコードベースを「敵対的視点」から自動分析できるようになる。
本来なら研究者に見つけられて攻撃されていた脆弱性も、先回りしてパッチを当てる機会が得られる。
だから、これを alignment 問題と呼ぶのは適切ではないように思う。
攻撃者が自動化で脆弱性を検出できるのと同様に、防御側もこの能力を持てる。
コミット承認プロセスやビルドごとに防御の自動化を組み込むことも可能だ。