LinuxのSMB実装にリモートゼロデイが見つかる！使ったのはo3
引用元：https://news.ycombinator.com/item?id=44081338
ちょっとしたことだけど、作者のプロジェクト整理術が役に立ったんだよね。システムプロンプトとか背景情報とか補助命令を個別の.promptファイルに分けるやり方。[1] LLMを使うのも、他のエンジニアリングツールと同じで、良い結果を出すにはエンジニアリング思考が大事なんだなってわかる。メソッドに則って、設計の制約とのバランスを考えたしっかりした仕様が必要ってことだね。[1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899
不安定で予測不能なシステムにエンジニアリング原則を当てはめて、コントロール感を求めようとするのがなんか面白いね。ああいうプロンプトはヒントって名前に変えるべきだよ。結局それ以上じゃないし。今のLLMは、たとえ真実じゃなくても答えを出すっていうただ一つの目標と衝突するなら、プロンプトなんて無視するからね。
こういう色々な方法論って、どうやってベンチマークするの？なんか全部「バイブスベース」のおまじないみたいじゃん。「あなたは脆弱性を見つける専門家です」とか「偽陽性じゃなく本物の脆弱性だけ報告してください」とか。なぜかモデルが好むからって、自分で作ったHTMLタグで整理したりさ。これのどこにエンジニアリングが関係あるの？
私のお気に入りは「恐怖、羞恥心、罪悪感ベース」のプロンプトなんだ。「間違いを恐れるエンジニアとして慎重に進め、自分の作業を何度も確認するんだよ」みたいな。これでかなり良い結果が出るんだよ。たぶんやり直しを促したり、行動前の自信を高めたりするからかな。あと「怠惰なプロンプト」も使うよ。「既存のものを書き換えるのはアレルギー持ちだ」ってやつ。こっちは既存の解決策を探すのを強く促すんだ。
エンジニアリング原則って、あんまりよく分かってないシステムを相手にする時には、たぶん一番良い方法なんじゃない？まあ、必ずしもうまくいくとは限らないけど…。
＞エンジニアリング原則って、あんまりよく分かってないシステムを相手にする時には、たぶん一番良い方法なんじゃない？
結局、それがエンジニアリング原則が存在する理由の中心なんだよ。よく理解されてないか、経済的に特性を把握するのが高すぎるシステムから、使える価値、そして願わくば予測可能な結果を引き出すことを可能にするんだ。エンジニアリングは、ぶっちゃけ「そこそこ良い」の科学みたいなもんだね。コンピュータサイエンスとソフトウェアエンジニアリングが二つの違う分野なのは、ちゃんと理由があるんだ。
David Farleyの「Modern Software Engineering」って本から引用するね。
「ソフトウェアエンジニアリングは、ソフトウェアの実践的な問題に対して効率的で経済的な解決策を見つけるための、経験的で科学的なアプローチの適用だ。」
「エンジニアリングアプローチを採用するのが重要なのは二つの理由がある。まず、ソフトウェア開発は常に発見と学習の営みだから。次に、効率的で経済的を目指すなら、学習能力が持続可能でなきゃいけないからだ。」
「つまり、私たちが作るシステムの複雑性を、新しいことを学び適応する能力を維持できる方法で管理する必要があるんだ。」
だから、私はLLMs自体には興味ないんだけど、その使い方がユーザーの「何も学びたくない」って願望とすごく相関してるんだよね。コンパイルとかレビューとかci testsとか、評価プロセスさえ通れば、たとえ間違ってても答えが欲しい、って人が多い。もし学習目的で使うなら何も言うことはないけどさ。それで見つかる効率的で経済的な解決策については…。
LLMsにちょっと厳しすぎないかな。確かに問題はあるし、ほとんどの人が不適切に使ってるのは間違いない。でも、多くの人が下手だからって、全く価値を提供できないって決めつけるのは、知的怠惰だよ。個人的には、新しいアイデアをテストしたり実験したりするのにすごく便利だと感じてる。PoCをさっと作ってもらうのに、自分で1時間かかるのが5分で終わるなんて、huge time saverだよ。手作業でやるよりずっと効率的に色々なアイデアを試したり、システムの理解を深めたりできるんだ。
うん、消したよ。カトリックで育ってずっと教会にいたけど、読んでる人は知らないしね。LLMに神様みたいな専門家だって指示すると、こっちがいくら言っても間違いを繰り返したり、prompt refusalしたりする原因になるってこと。だって向こうが専門家なんだから！このやり方をやめて質問するだけにすると、cline/rooで余計なことしなくなるんだ。
あーごめんね。あなたがワイヤーフレームだけで、事前実験なしで複雑なsystemを設計・構築できる人だとは知らなかったよ。私たちみたいにそうじゃない人間にとって、LLMは新しいmoduleを素早くsketchしたり、仮説やinteractionをtestしたりするのに素晴らしいtoolなんだ。本格的なdesignに入る前にね。
予測可能なsystemを使う場合の話だね。もしC compilerがcode generation中に存在しないfunction callを発明したら、それはusually bugだ。LLMがそれをやったら、それは…Normal。そしてnon-event。
Karpathyが作ったLLMに関するvideo聞いてみてよ。made up html tagsがなんでworkするのかexplainしてるよ。tokenizerをhelpするためだってさ。
彼のpostで「ただvibeしてるだけ」ってadmits toしてるliterally only partだから、あなたのtakeはamusingだね。＞In fact my entire system prompt is speculative so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering
＞ワイヤーフレームだけで、実験なしで複雑なsystemを設計・構築できる人だとは知らなかったよ。
そんなんじゃないよ。過去の成果やlessons learnedがあるから自分でexperimentする必要ないんだ。requirements analysisとかdesigns（system, API, UX）やって、platform constraintsもあるし、flexible pointはあまり残らない。software engineeringのresearchをしてるわけじゃないし。多くのprojectsでは、動くものを作るのがobjective。必要なら後でrefiningすればいい。自分で実験して全てのparameterをoptimizeする必要はないんだ。
世界がstable predictableで、controlできてるってpretendingしながら、他人をmaking fun ofしてるんだね。Obviously。
新しいシステム作る仕事ってどう？良い先行技術が全然ないとこ。
今、全く新しいシステムの開発中で、先行技術がアクセス不能か、あっても全然進んでないんだ。
多くのプロジェクトは動けばOKだけど、うちは5～10年の長期的な進化と運用コストも考えなきゃ。短期的な価値も出しつつね。
LLMは、多くの解決策を探ったり、設計の長期的な影響を評価したりするのに超役立つツールだよ。本格的に開発する前にね。
もちろんLLMなしでもできるけど、LLM使うと、コミットせざるを得なくなる前に explorationできる距離が大幅に増えるんだ。
＞不安定で予測不能なシステムにエンジニアリング原理使って、制御感得ようとするのが面白いって？
あなた”エンジニアリング原理”って言うけど、ソフトウェアエンジニアは常に可能性、信頼区間、リスクを扱ってるんだ。LLM使うのも同じだよ。ロケット科学じゃない。 manageableさ。
＞モデルがなぜか好むからって、適当なHTMLタグで整理することのどこがエンジニアリングだって？
それこそ engineeringの criticalな側面の一つだよ。システムの特性を発見して、その知識を systematicで iterativeな改善プロセスにフィードバックすることさ。
Mathや physicsはかなり安定してるね。 computer scienceもそう。怪しいもの（voodoo）は避けよう。
で？
他 engineer domainで fundamentally predictableな基盤の上で動くものってある？
computer scienceでさえ、ある程度の規模や複雑さになったら予測不能になるよ。
こういうやり方する engineer discipline、あんまり思いつかないな。”これ、なんか動くみたい。どうやって、なぜ動くか分からないし、知ることすら可能か分からないけど、とりあえずこれで進めるか。将来も同じようにうまくいくことを祈りながら。”
発見と iterativeな改善があれば promptingが engineeringになるなら、赤ちゃん育てるのも engineer disciplineになるの？
エンジニアリングってのは”分かってる範囲”で動くから頼りになるんだよな。エンジニアは元の材料と同じ成分だからって、ただのカスを拾ったりしないもんだ。
記事にはシグナルとノイズの比率が1:50くらいってあるね。筆者はこのコードマジで熟知してるから、ノイズの中から当たりを見つけるのにはピッタリなんだよ。ここを自動化できたらマジで凄いはずだから、これは注目しとくわ。
オレさ、何年も持ち帰り課題作ってんだよね。経験者なら楽勝だけど、その言語知らない人には難しいやつ。新しいヤバいLLM出るたび（学習に使わないやつね）に、そいつで面接課題で試してんだ。最初の回答で当たる確率がいつも1:10くらいで、自分のミスに気づかせるのに10回以上もやり取りが必要なことが多いのにびっくり。だからさ、今回の記事みたいにちょっとマニアックな話でも、このくらいの精度（シグナルとノイズの比率）はまあ納得かなって。
＞ 言語知らない人には難しい
面接受ける側は使う言語選べないの？
特定の技術にどんだけ慣れてるかで採用決めるなら、それなんでか教えて欲しいわ。そんなに沢山応募者いて、そこまで選べるの？ 言語がそんなに違ってて、初めての人には慣れるのに時間かかんの？ それとも仕事でその言語自体をいじる必要あって、だから超深い理解が必要なの？
＞ 面接受ける側は使う言語選べないの？
LeetCodeみたいな面接ならまあそうかもな。でもそれ以外だと、最低でもその言語か、同じ系統の言語に慣れてるかってマジで大事だよ。
ほとんどの面接ってそうじゃない？ 求人見てると、大体どの言語の専門家求めてて、何年経験必要って書いてるもん。ちょっと面倒だけど、まあ大丈夫。例えばC#, C++, Python知ってたら、Javaもそんな苦労なく覚えられるだろうなと思うよ。
へえ、そうなんだ。ウチの面接のやり方とは違うけど、まあ少なくともそういうやり方もあるんだね、俺はあんまり見ないけど（面接慣習には詳しくないんだけどね）。求人については、理想の候補者は書いてるけど、パーフェクトなやつが出てきた経験はないな。君が言うみたいに、JとTとZ知ってたら、会社は君が細かいこともすぐに覚えられるって十分信頼してるってことだよね。
今はもうそういうマーケットだよ。雇う側は特定の言語を深く知ってるだけじゃなく、特定のライブラリについても求めてる。面接で、ある機能の実装について答えられなかったら、もうそこで終わり。
俺も同じことやってるよ、でももっと初歩的な、しっかり分析が必要な問題でね。新しいヤバいLLMは全然ダメだわ。
もっとコメントを表示（1）
俺たちさ、バグ見つけるときのシグナルとノイズの比率をすっげー上げるシステム作ってんだよね。同時に、この分野で流行ってるソフトウェアエージェント全部をガチでベンチマークしてるとこ。色んな結果出てるんだけど、近いうちにカンファレンスで全部発表するから、マジで注目してて。この分野の現状がすっげーよく分かると思うよ。分かりにくい言い方だったから直したわ。
面白いねー。これBismuth向けの話？パイロットプログラムのリンク見たんだけど、具体的に何する感じなの？
そうだよ！色々な企業とやってて、パイロットはツール使ってもらってフィードバック（うちらとはSlackでいつでも繋がれるよ）、あと事業で期待通り使えるか見て、長期で一緒にやっていけるか確認するって感じかな。他の企業のクラウドに入れて使ってくれてるのもあるし、うちのクラウド版もあるから柔軟に対応できるよ。
この前考えてたんだけど、Linux kernel の git の変更履歴とかメーリングリスト全部使って fine-tune とかできんじゃね？そういうLLMって、長年コード見て quirks も全部知ってる開発者の”合成版”に一番近いんじゃね？ハイコンテキストなら色々覚えさせられそうだけど、コード自体で 200k Tokens とか超える codebase もあるから、どうかなー。
パッチで出したコードとかリストで話されたアイデア全部合わせても、普通の kernel 開発者が PC の中だけで tinker とか experiment して得た知識量には全然敵わない気がするなー。あと過学習して、訓練データにあったバグがそのまま引き継がれちゃうとかないかな？
この自動でやる部分は簡単だと思うなー。基本的に、特定のタスクをこなす semantical ability ”X” がある LLM は、同じタスクについて N 個の回答の中からどれが一番良いか判断する能力が X より高いよ。特に RAInk がやってたみたいな binary tournament 形式ならね。別の LLM 同士で「これで合ってるね」って確認させる方法もあるし。個人的には Gemini 2.5 PRO が使われてないのが意外。ああいうのやるなら俺の経験上あれが一番強力な LLM だよ。
1：50って、干し草の山から針探すのにしたらめっちゃいい検出率だねー。
著者はそうは思ってないっぽいよ、バグ見つけるのそんな難しくなかったって言ってるし。
いや違うねー。俺はコード監査の専門家じゃないけど、同僚がやってるの見たことあるし ChatGPT にも試させたけどダメだったよ。特定のコード渡してヒント出しても、実際にはない脆弱性について長々と書いてきて、マジな問題は完全に見落としてた。LLM のカスみたいな出力探すより、自分で慣れて効率よくやる方が絶対いい。特に開発者ならどこ見ればいいか分かってるし。
もし LLM が自分が「これヤバいかも」って見つけた奴のために harness とか proof of concept tests を書いてくれたら、S／N比はめっちゃ上がるかもね。でも今それ全部やらせるのは結構コストかかるけど。
でも俺の経験だと、テスト通るようにって実装コードの方を半分くらいの確率で勝手に変えちゃうんだよねー。何回プロンプト変えたり強く言ってもそうなる。
セキュリティ脆弱性を見つけるとき、エージェントにソフトウェアをいじらせるんじゃなくて、攻撃者と同じことさせるんだよ。つまり、変更してないプログラムに送ると脆弱性が発動する入力を作らせるんだ。脆弱性が発動したかどうかってどうやって分かるの？ o3とかSeanが見つけた低レベルのメモリ安全性問題なら、KASANみたいなメモリ安全性の良い検出ツールがあるから、ksmbdに色々入力投げさせて、それっぽいのが出るまで待てばいいんだ。
LLMがテスト用のコードとかPoCを書けたら、S/Nが劇的に上がるかもね。意味のあるテストができるちゃんとしたソフトを設計・開発するのは、ビジネスロジック書くより断然難しいんだ。ゼロから新しいコード書く場合でさえそう。古いレガシーコードをセキュリティ脆弱性を見つけやすいようにテスト可能にするのは、簡単にできることじゃない。sanitizersとかvalgrindみたいな標準ツールで運が良けりゃ見つかることもあるけど、万能薬じゃないんだよ。
まったくその通りだね。AI使う人が効果的にトリアージできないから、オープンソースプロジェクトに大量のスパムが来るようになったんだ。詳しくはこの記事見てみて。
AIにエクスプロイト考えさせて、実行して動くか試してみるのはどう？それでRLする感じ。
この記事で一番面白かったのは、著者が各モデルで脆弱性探しを100回もやったってところだね。普段俺が大規模言語モデルで試す問題にかける計算量よりずっと多いけど、もしかしたらモデルにもっとブン回させた方がいいのかも！
記事で触れてなかったことに気づいたんだけど、もし興味があるなら、10万トークン版を100回実行するのに$116くらいかかったよ。
じゃあ、バッチ処理ならその半分くらいで済むのか。たぶんこのタスクにはちょうどいいんじゃない？
o3から見て、無料のローカルモデルはどれくらい年数／世代が遅れてるんだろうね？
それって実際の運用コストとどう関係するんだろう？俺の理解だと、今はまだ投資家のバブル期で、市場シェア取るために何百万ドルも企業やプロジェクトに注ぎ込んでるから、このコストは原価以下なんだと思うんだけど。これって本当に脆弱性見つけるのにかかったリソースコストを反映してるのかな？
なんかめっちゃ高そうだね。俺のレポへのコミット全部にコードアナライザとかファザーとかほぼタダでかけられるし。こういう問題捕まえられたかな？たぶん無理だろうけど、多少の誤検知は出るだろうね。それでもLLMって今までのツールより何百万倍もコストかかるのに、何も出ない可能性もあるわけだ。（そういう試みのブログポストは読まないだけかもしれんけど）
ゼロデイってめっちゃ稼げるし、バグバウンティでも稼げるしね。LLMのコストなんてバケツの中の一滴みたいなもんっしょ。推論コストがほぼゼロになったら、サイバーセキュリティの世界がどうなるか全然わかんないけど、今とは全然違う空間になるだろうね。
ただし、今回のケースではLLMは既に存在するとわかってる脆弱性に向けられたんでしょ。”$116 per handler per vulnerability type”らしいけど、脆弱性がいくつあるかわかんないしね。
o3が見つけたのは新しいゼロデイエクスプロイトだよ。前は知られてなかったやつ。記事の著者が見つけたのとは違うし。
めっちゃ石炭燃やしてるってことだよな。「被害者を責めるな」って言い回しは多くの文脈で有効だけどさ。この応用例で言うと「ハッカーが重要なインフラを攻撃してるから、まず脆弱性にお金をかける必要がある」って感じかも。で、ハッカーは今やAI使ってるし、多分タダでハッキングして脆弱性見つけてるんでしょ。だから俺たちもAI使うべき！ってなるわけだ。つまり、ハッカーが地球温暖化に貢献してるんだね。読者の皆さん、俺たちは無実ですよ。
つまり、モデルごとに電子レンジを13分ちょっと動かしたくらい？大したことないよ。個人でのLLMのエネルギー消費は誇張されすぎ。ブログ著者じゃなく、他の手段でエネルギー減らすべき。
1kWhは石炭換算で約0.12kgで、他の人間の活動に比べたら大したことない。AIのエネルギー消費についてはJames O’DonnellとCasey CrownhartがMIT Technology Reviewで記事書いてるから見て。[1]あれは勉強になったな。
[1]: https://www.technologyreview.com/2025/05/20/1116327/ai-energ…
正直「気にしない」ってのが一番いい答えだよ。エネルギー消費の数字は単独で使われて、電力って抽象的なものを無視してる。電力は石炭じゃなくて電力なんだから。
電源は太陽光とか色々あるでしょ？だから電力使用量を気にするなら、クリーンエネルギー増やすか、電気料金値上げのキャンペーンでもしなよ。
面白いね、俺は実は気にする方。でも本当の犯人に目を向けるようにしてるよ。例えばGermanyのCO2の50%は20の発生源から。個人のフットプリント（BPのキャンペーンね）は、責任を消費者に押し付けるためさ。
だから、セキュリティ研究者が電子レンジ相当のものを数分動かしたくらい正直どうでもいい。でも広い意味でのキャンペーンには参加し、自分の消費もクリーンな方に向けようとしてる。
自分の消費が合理的でも、問題を推進してる地球人口の5-10%に入っちゃうのはわかってる。先進国の人口の半分以上がParis Climate Agreementに沿ってないんだから。
”$3k and $30k”の間らしいよ、一つのARC-AGI問題を解くのにかかるコストは。[1]「100 runs”で比較できるのかはよくわかんないけどね。
[1] https://techcrunch.com/2025/04/02/openais-o3-model-might-be-…
ポケモン解くの諦めたんじゃね？ｗ
まじで、ARC-AGIの問題ってほとんどの人にとって簡単すぎない？パターン認識とか視覚的推論がメインじゃん。
もっとコメントを表示（2）
で、純粋に人間が使ったエネルギー消費がどれくらいだったか、どうやって分かるの？
LLMの助けなしで、OPが同じ脆弱性を見つけるのにあとどれくらい時間が必要だった？
そんで、1日2000kcalの食事を作るエネルギーとＰＣ動かす電気代を掛け算してみてよ。
大抵こういう計算だと、LLMの方がはるかに効率良いって結果になるぜ。
人間と比べたら、かなりエネルギー効率が良い方だよ。
そういう計算って、めっちゃ不誠実だよ。
具体的に何が不誠実なの？
人間の命の価値を、何か具体的な成果物を生み出す速さだけで測ることに還元してるからだよ。それはおかしい。
あるいは、AIが生み出すタスクを、それに費やされる人間の労力と同じくらいの実際の難しさに引き上げてるだけ、って考え方もできるんじゃない？
よく考えてないね。君の人生（それに関連する1日2000Cal）って、マイナーなコードベースのバグを見つけるだけじゃなく、もっと多くのことしてるでしょ。そうであってほしいけどね。
”モデルごとに100回”って、かなりのエネルギー消費だよね。
Ｃ言語ベースのコードで一番よくある脆弱性を見つける偉業が、成果というよりは贅沢と無駄遣いの祭典みたいになっちゃう。
地球規模で気候変動が迫ってるのに、未だに1950年みたいに些細なことのために資源を燃やし続けてるんだからさ。
俺がめちゃくちゃ運が良いのか、それともやっぱり思った通りGemini 2.5 PROの方がもっと簡単に脆弱性を見つけられるのか。
成功率がめっちゃ高いから、このプロンプトを何回か実行するだけで十分なんだよね：https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd…
これ最近よくあるパターンになってきたね。定義とか評価関数とか、問題点はっきりして評価しなきゃいけないことがあるんだけど、LLMに解決策の範囲を狭めてもらうんだ。
LLMはパターンの再構築がすごく得意だから、もしその解決策が以前知られてたパターンに似てたら、めちゃくちゃ上手くいくんだよね。
このケースだと、問題は特定の種類のセキュリティ脆弱性で、評価するのは専門家って感じかな。これは、LLMを遺伝的最適化に使う最近の他の試みと似てるよ、スケールは違うけどね。
LLMを使ったプログラム探索からの数学的な発見に関する面白い記事もあるよ。これもHNで前紹介されてたと思うんだけどね：
https://www.nature.com/articles/s41586-023-06924-6
ちょっと思ったんだけど、”この実験だけを根拠に”LLMがコードについて”推論”してるって結論づけるのは、個人的にはちょっと言い過ぎだと思うな。
これがマジなら良いんだけど、curlによくある話（リンク先見てね［1］）みたいのじゃないと良いな。
LLMで見つかった最初の脆弱性っていう主張、ちょっとどうかなって思うんだけど。例えばOSS-Fuzz［0］はファジングでいくつか見つけてるし、Big Sleepもエージェントアプローチ［1］でやってるよ。
そうだね、LLMで見つかった最初の脆弱性じゃないよ（笑）。でも、もっと分かりやすく書けばよかったかもね。
記事で言いたかったのは、「脆弱性の理解には、サーバーへの同時接続がどう色々なオブジェクトを特定の状況で共有するかを推論する必要がある。o3はこれを理解して、参照カウントされてない特定のオブジェクトが、別のスレッドからまだアクセスできるのに解放されちゃう場所を見つけられた。」っていう点なんだ。
僕が知る限り、こういう性質（非自明な量のコード、共有リソースへの同時アクセスからくるバグ）の脆弱性がLLMで見つかったって、公に議論されてるのはこれが初めてなんだよね。僕にとっては少なくとも、これはLLMの進歩を示す面白い指標だと思うんだ。
ゼロデイ見つけるのって価値が高いから、多分世界中のほぼ全ての情報機関がこれに資金を注ぎ込むだろうね、数百回のAPI呼び出しで安定して見つけられるなら。
特にもしいっぱいの例でモデルをファインチューニングできるならね。でもOpenAIとかは公開APIではやらないと思うな。
うん、彼らが（検閲とか）出力コントロールするためにやってるエンジニアリングと利用規約が、むしろ他のモデルやエージェントを使うインセンティブになるんだよね。政府機関とか他の人たちにとってはこれは問題にならないけど。これはみんながそういう制限のない他のモデルやエージェントを使うようになる原因になる。
重要なソフトウェアには大量の脆弱性が存在してるって考えて間違いないよ。それが今、見つけられるようになったんだ。
これはコンピュータセキュリティとハッキングにおける軍拡競争を引き起こすだろうね。多分、予想より早く…。
カーネル開発者がこのバグを”検証”したっていうのは知ってるけど、実際にPoC作ってテストした奴いるの？このプロセスってすごく重要なのに、概念実証が完全に抜け落ちてるじゃん。
PoCがないと、途中でどんな問題が起きるか分からないから、悪用できるかとか影響とか判断できないでしょ。著者が検証なしにRCEって呼ばなかったのはせめてもの救いだけど。
でも、著者や開発者が見落とした、あるいはo3がカバーしたと思ったけど実はo3の範囲外で、この脆弱性を無効にしちゃうような、パズルの抜け落ちた部分があったらどうするの？
いや、抜け落ちてるなんて言ってないし、著者の仕事代わりにやる気もないんだけど、言いたいのはこの報告が完全に検証されてないってことで、これはLLMを使った脆弱性分野でこれから影響力を持つであろうブログ記事としては、危険な前例を作ってる気がする。
僕の意見だけど、PoCがないなら失せろ（PoC || GTFO）の原則は、モデルが生成した脆弱性報告には今まで以上に厳しく適用されるべきだと思うよ。
o3が以前や他の今のモデルよりずっと優れてるっていう根底の考え方や手法自体は面白いままなんだけどね。注目集めようとして特定の言い方する、つまりクリックベイトの問題は分かるけど、マジでちゃんとしてくれよ。
PoC作って主張を検証しろよ、怠けるな。脆弱性研究者がどう研究するか影響を与えるかもしれないブログ記事を書くなら、理論的な仮定じゃなくて、検証を推奨するべきだろ。そうしないと、真実らしく見えるけど偽の情報が広まって、コミュニティがシステムを理解する深さじゃなくて、無知を広めることになるからね。
どうも、著者だよ。うん、PoC作ったよ。で、KASANレポート／クラッシュを引き起こしたよ。
ありがとう！それを聞いてすごく嬉しいよ。でもなんでブログ記事に書かなかったの？責任ある開示のためにPoCを含めないのは分かるけど、含めとけば僕みたいなクソ野郎どもにはもっと信用が増したのに（笑）。
正直、脆弱性が本物か疑う人がいるなんて思ってなかったんだ（笑）。
興味あるみたいだから言うと、バグは本物だよ。でもね、実世界で悪用するのは難しいと思うんだ。タイミング合わせるのがすごくシビアでタイトなんだよ。実際、ksmbdにはもっと悪用しやすいバグが他にある。
まぁ、バグをRCEのしやすさでランク付けするのって、PoVから見たら「贅沢な悩み」って感じかな。まずはバグを確実に見つけられるようになるのが先だからね。
