ハクソク

世界を動かす技術を、日本語で。

o3を使用してLinuxのSMB実装におけるリモートゼロデイを発見しました

366日前原文(sean.heelan.io)

概要

  • OpenAIの o3モデル を使い、Linuxカーネルの ゼロデイ脆弱性 を発見した事例の解説。
  • ksmbd （SMB3プロトコルカーネルサーバ）の脆弱性調査の流れを紹介。
  • o3による既知脆弱性（CVE-2025-37778）発見のベンチマーク結果を詳細に分析。
  • o3が新たなゼロデイ（CVE-2025-37899）を自動的に指摘した過程を説明。
  • LLMの現状と今後の脆弱性研究へのインパクトについて考察。

OpenAI o3モデルによるLinuxカーネル脆弱性発見事例

ksmbdと脆弱性調査の背景

  • ksmbd はLinuxカーネル内で動作する SMB3プロトコルサーバ。
  • SMB3はネットワーク越しにファイル共有を実現するプロトコル。
  • 調査目的は、 LLM関連ツール開発 からの一時的な休息を兼ねた脆弱性監査。
  • o3リリース後、既知バグを使い o3の能力ベンチマーク を実施。

CVE-2025-37778（Kerberos認証脆弱性）の概要

  • Kerberos認証処理中 の“session setup”リクエスト処理における use-after-free 脆弱性。
  • sess->stateが SMB2_SESSION_VALID の場合、 sess->user が解放される。
  • ksmbd_krb5_authenticateによる再初期化が行われない場合、解放済みポインタ利用が発生。
  • 発見・再現には 3.3k LoC 程度のコード理解が必要。
    • a. sess->state == SMB2_SESSION_VALID を成立させる条件の特定
    • b. sess->userが再初期化されないパスの特定と誘導
    • c. 解放後にsess->userへアクセスする箇所の特定

LLM評価環境とプロンプト設計

  • LLMには “session setup”コマンドハンドラ と、その呼び出し関数群（深さ3まで）を入力。
  • パケット受信からハンドラ実行、接続終了まで の一連のコードを含める。
  • システムプロンプトでは「use-after-free脆弱性の検出」「ksmbdの概要・脅威モデル」を明示。
  • 誤検知抑制 を強く指示する設計。

o3による検出結果と他モデル比較

  • 100回実行 でo3は8回脆弱性を検出（8%）、66回は未検出、28回は誤検知。
  • True Positive:False Positive比 は1:4.5（最大5誤検知で1本物発見）。
  • Claude Sonnet 3.7は3回、Claude Sonnet 3.5は0回と比較し、 o3は2〜3倍高精度。
  • o3の出力は 簡潔かつバグレポート風、Sonnetは思考過程型。

o3によるゼロデイ（CVE-2025-37899）発見

  • “session setup”以外も含む smb2pdu.c全体（約9k LoC） を対象にo3へ入力。
  • 入力トークン増加で検出精度は低下（1/100回）するが、 新規脆弱性を自動指摘。
  • 新規脆弱性は“session logoff”ハンドラでの sess->user解放 に関するuse-after-free。
  • 複数スレッド が同時に同じセッションを扱う場合、解放済みポインタ参照が発生。
    • o3は 同期処理の欠如 と 競合条件 を正確に推論し、脆弱性を報告。

LLMの脆弱性研究へのインパクトと今後

  • o3のコード理解・推論能力 は大幅に進化。
  • 10k LoC未満の問題なら o3が解決や支援できる可能性 が現実的。
  • LLMは専門家を 置き換えるものではなく、効率化・高度化を支援 する存在。
  • 脆弱性研究者やエクスプロイト開発者は LLM活用による生産性向上 に注目すべき段階。
  • 今後も LLMの進化と脆弱性検出自動化 の動向に継続的な注視が必要。

Hackerたちの意見

ちなみに、私はこの投稿の作者じゃないよ。「How I」で始まるタイトルなだけだから。

記事では、信号対雑音比が約1:50と引用されてるね。著者はこのコードベースにかなり詳しいみたいだから、信号と雑音をうまく分けられる立場にいるんだろうね。この部分を自動化するのが本当の勝利になると思うから、注目してるよ。

└

そういえば、最近考えてたんだけど、Linuxカーネルが今までにハードしたすべてのgit変更やメールリストにファインチューニングみたいなものを入れるのって、現実的じゃないかな？そんなLLMは、何年もコードベースに関わってきた人の近い-合成-バージョンになるんじゃないかな。高いコンテキストに収められることがたくさんあるし、いくつかのコードベースはそのままで20万トークンもあるから、どうだろうね。

└

1:50は、針を見つけるには素晴らしい検出比率だね。

└

その通りだね。多くのAIユーザーは効果的にトリアージできないから、オープンソースプロジェクトにはスパムが多くなってるんだよね。

└

バグを見つけるための信号対雑音比を劇的に向上させるシステムに取り組んでるんだ。それと同時に、人気のソフトウェアエージェント全体のベンチマークも徹底的にやってる。いろんな結果が出てきたし、もうすぐカンファレンスで全てを公開する予定だから、楽しみにしてて。かなり面白い内容になると思うよ。編集：言葉が分かりにくかったね。

└

LLMがハーネスとリードのための概念実証テストを書いたら、信号対雑音比が劇的に上がるかも。ただ、今はそれを全部やるのはかなり高くつくんだよね。

私の理解では、ksmbdは「軽量で高性能な代替品」として開発されたカーネル空間のSMBサーバーなんだよね。Q1: 誰がプロダクションでksmbdを使ってるの？ Q2: なんで？

└

軽量で高性能だから、って理由だと思うけど？

└
  1. SolarisやWindowsのカーネル内SMBサーバーを使ってた人たち。2. Sambaのパフォーマンスは（比較すると）ひどいから、2025年でもファイル共有にはWindowsが定期的に使われてる。これって、ファイルの権限に対してネイティブのWindowsスタイルのACLをサポートしてるのかな？それがSolarisを使い続ける最後の理由なんだけど、ZFSに依存してると思う。SambaはUnixのUID/GIDに依存してて、そのセキュリティモデルの一部として同期を行ってるけど、残念ながら1970年代に取り残されてる。注意点として、カーネル内SMBサーバーはWindowsで少なくとも一つの「これはヤバい」なゼロデイリモートルートホールの原因になったことがある（Solarisについては不明）から、トレードオフがあるよ。
└

ライセンスについて。SambaはGPLv3だけど、LinuxはGPLv2だけなんだよね。

└

kmod-trelayを使う理由は、relaydの代わりに使うってことだと思う。

この文章で一番興味深くて重要だと思ったのは、著者が各モデルで脆弱性の検索を100回も実行したことだね。これは、私が大規模言語モデルで試す問題に対して、今までにかけてきた計算量よりもかなり多いけど、もしかしたらモデルを「バrrrrrr」って動かしてみるべきかも！

└

お金さえあれば、何でもできるよね〜

└

ゼロデイは$$$で売れるし、バグバウンティのルートを選んでも$$がもらえる。LLMのコストはほんのわずかだよね。推論のコストがほぼゼロに近づいたら、サイバーセキュリティの世界がどうなるか全く想像できないけど、今とは全然違う空間になるだろうね。

o3を使うと、人間が書いたバグレポートのような感じで、結果だけをまとめて提示してくれる。一方、Sonnet 3.7では思考の流れや作業ログのようなものが得られる。これは、著者がClaudeに考えるためのスペースやスクラッチパッドを与えなかったからだと思う。結果的に、報告と考えを混ぜてしまったんだ。公式の思考メカニズムを使うことで、異なる結果が得られるだけのスペースが与えられるかどうか、興味があるな。

└

両方試してみたけど、o3は3.7やGemini 2.5 Proとは別格だと思う。ベンチマークではあまり差が出ないかもしれないけど、タスクがすごく複雑なときにはそれが大事なんだよね。驚くべきことに、去年の11月に発表して、ようやく先月リリースされたの？（安全性のために時間がかかったのかな、よくわからないけど）。o4が待ちきれない！

小さなことだけど、著者のプロジェクト整理のやり方が役立ったよ。システムプロンプト、背景情報、補助指示のために個別の.promptファイルを作って、それをllmで実行するっていうやり方ね。良いLLMの使い方は、他のエンジニアリングツールと同じように、良いエンジニアリング思考が必要だってことが分かる。方法論的で、設計制約をバランスさせた思慮深い仕様に基づいてるから、最高の結果が得られるんだ。

└

これらの異なる手法をどうやってベンチマークするんだろう？なんか雰囲気で呪文を唱えてるみたいだね。「君は脆弱性を見つけるのが得意だ。」とか「本物の脆弱性だけ報告して、偽陽性は報告しないでね。」みたいな。モデルがなんか好きそうだから、作ったHTMLタグで整理してるけど、エンジニアリングはどこに入ってくるんだろう？

└

人々が本質的に不安定で予測不可能なシステムにエンジニアリングの原則を適用しようとするのが面白いね。あのプロンプトは「ヒント」って名前に変えるべきだよ。だって、あれはそれだけだから。今のLLMは、プロンプトがその唯一の目的、つまり真実かどうかに関係なく答えを出すことと矛盾する場合、無視しちゃうからね。

これが本物であって、curlに起こることが繰り返されないことを本当に願ってるよ。

短期的には、これがLLMの最大のアラインメント問題だと思う。これが恐ろしいほど上手くなってきてる。最近、たまに使うオープンソースのニッチなサーバーでかなり深刻なセキュリティ脆弱性を見つけたんだ。LLMを使ったらほとんど労力がかからなかった。手動で脆弱性を見つける価値がなかったソフトウェアがたくさんあって、自動化されれば本当に深刻な問題につながるんじゃないかと心配してる。

└

このコインの（明らかに）裏側は、自分たちのコードベースに対して敵対的に実行できるってことだね。研究者が見つけられたかもしれないバグをキャッチして、代わりに先にパッチを当てられる。個人的には、これをアラインメントの問題とは呼ばないけど。

└

攻撃者が自動でコードの脆弱性をスキャンできるなら、防御側もできるよね。コミット承認プロセスの一部にしたり、すべてのビルドをスキャンしたりできるかも。

ここに、私のプロンプト開発セッションの大半を完璧に捉えた素敵なスニペットがある：> 「偽陽性を報告しないように強く誘導し、偽陽性を報告するよりもバグを報告しないことを優先させようとした。これが役立つかどうかわからないけど、役立ってほしいから、こうしてるんだ。実際、私のシステムプロンプトは、役立つか妨げるかを判断するための評価を十分に行っていないから、科学やエンジニアリングに似たものではなく、祈りを捧げているのと同じだと思ってほしい。評価を行ったら、結果を教えるよ。」