PHPの脆弱性に「簡単な攻撃法」は存在しない
There isn't an easy exploit for this PHP vulnerability
PHPの新たな脆弱性をめぐり、GitHubには数千ものPoCが溢れているが、素のPHPに対して動くものは一つもない。LLMが生成した「攻撃コード」の多くは、サーバー側に別の脆弱性を仕込むことで成立させているだけだ。Log4ShellやHeartbleedのように即座にボットネットが動き出す事態には至っておらず、筆者はLLMへの過信が判断を歪めていると指摘する。
皮肉なことに、LLMは弟にコントローラーを渡すようなものだ。画面にはexploitと表示され、決定的な証拠のログまで出ている。しかし実際には、テスト対象のサーバーに重大な脆弱性を仕込んでいたのだ。ずるだ。
HNでの議論
389- nallerooth
サイバーセキュリティの分野で知識があるように見せたい人が言うには、ずいぶん奇妙な主張だ（この人が実際に詳しいのかもしれないが、私はこの人物が誰なのか全く知らない）。たとえこのエクスプロイトを適切に使うのが難しくても、試みているグループが世の中に存在しないわけではない。
これに真剣に向き合う人なら、動作するPoCがPHPのセキュリティチームに報告されたという事実を考慮するはずだ。彼らは脆弱性を確認し、2つのCVEを報告し、公式パッチのリリース前にLinuxディストリビューションへパッチを配布するなど、その深刻さについて大いに騒ぎ立てた。
この投稿のメッセージが一体何なのかを理解しようと、頭の中で全体をひっくり返してみた。するとそのメッセージは要するに「サーバーをアップグレードする必要はない」ということになる。これは動作するエクスプロイトを持っている人が言いそうなことだ。あるいは、単なるインターネット上のノイズにすぎない。
- hn773746483
ソーシャルメディアと「サイバーセキュリティの専門家」たちが、これに大きな役割を果たした。「EUがこれは緊急の脆弱性だと言っている」といった類のもの、さらには日本の総理大臣が夜間に注意喚起を行うまでになった。彼らは最初のアドバイザリについて、ソーシャルメディア上の「専門家」の投稿を引用する一方で、まさにその同じいわゆる専門家たちがGoogle検索のAI出力による緩和策を共有している。これらの組織や機関のいずれも、アドバイザリとソーシャルメディアに載っていた以上の詳細は持っていなかった（例：「CVSS 10、これはまずいぞ！！」）。
私には、これはむしろBroadpwnに近いように思える。技術的には深刻で、影響範囲も広く（数百万台のiPhone）、それでも万能のPWNボタンになることは決してないだろう。
AIの時代になっても、これが後々Eternalblueのように武器化されることはないと思う……が、私はフォロワー15000人のソーシャルメディアのサイバーセキュリティ野郎ではないので、私の言葉を鵜呑みにしないでほしい ;)
- tibbar
2つのことは同時に真であり得る。すなわち、これは実際に悪用可能なCVE 10であり、かつ、LLMがズルをしないようにするための優れたハーネスと検証プロセスを用意しなければならないほど構築が難しい、ということだ。つまり、エクスプロイトの構築は簡単ではないかもしれないが、投稿者が示唆したような人工的な設定を実際に必要とするわけではない。
> 私たちが実証したこと
> WordPress、Drupal、Joomlaにおける認証前RCE
- nemothekid
私にとって奇妙だったのは、この脆弱性が実際にどう機能するのかについての解説記事が全くなかったことだ。多くの人が「Claudeがバグを見つけた、そしてClaudeが危険だと言っている」で終わってしまい、実際にどれほど悪用可能なのかを誰も検証していないように本当に感じる。無視する価値があると言うつもりはないが、Heartbleed（エクスプロイトを手書きする必要があった）と比べると、稼働しているPoCはずっと少ない。
- apexalpha
これは間違いなく悪用可能だった。動作しないPoCが1000個存在するからといって、動作する1個が無効になるわけではない。
確かにバニラのインストールでは無理かもしれないが、ほとんどの人はPHPを自分でインストールせず、既製のコンテナや内部でPHPを使っているプラットフォームを使っている。
昨日、私は単純にもうセキュリティに自信が持てなくなり、データベース内のデータは数時間オフラインにする価値があるほど重要だった。
- kgeist
今日GitHubから2つのPoCを実行してみた。1つは実際にLocal File Inclusion（LFI）がすでに存在していることを前提としていた（つまり余計な手順が付いただけのLFIだ）。もう1つは、同じDockerイメージなどを使ったにもかかわらず、多少の修正を加えなければそのままでは全く動作しなかった。2つ目のPoCは最終的に本物のstale writeバグを引き起こしたが、実際のRCEを実証したわけではなく、stale writeを引き起こしただけだった。そこで思ったのだが、PHPランタイムにメモリ破壊バグが存在したのはこれが初めてなのだろうか？そうは思わない（数年前、高負荷時にopcacheのバグが原因で本番環境でランダムにクラッシュしたことを覚えている）。そして、PHPランタイムにおける初めてのメモリ破壊バグではないのなら、なぜこれがここ数年の最悪の脆弱性だと喧伝されているのだろうか？
- nickysielicki
Wordpress、Joomla、DrupalのDockerイメージはすべて悪用可能だった。
- rectang
https://news.ycombinator.com/item?id=50182987 で議論されている「Today's PHP Security Release, and How We're Strengthening PHP Security」によると：
* 一方のCVEについて、「アプリケーションレベルのコードパスを通じてPHP-FPM上でのリモートコード実行も確認された」
* もう一方のCVEについて、「use-after-freeとワーカーのクラッシュが確認され、報告者はmod_phpを搭載したApache上で動作する実アプリケーションに対するリモートコード実行を実証した」
これらのエクスプロイトが存在する以上、LLMはすぐにそれらを複製するだろうと私は予想している。
- easterncalculus
偽のエクスプロイトが出回っていることに関するLiveOverflowの関連動画 https://www.youtube.com/watch?v=7CiZmq2llDg
とはいえ、投稿者は基本的にデタラメばかり言っている。これは間違いなく悪用可能であり、人々はプラットフォームとABIを勝手に想定してインターネットに対してばら撒くだろう。特にmod_phpを狙って。
- 0x1F8B
これが悪用不可能だとそんなに自信があるなら、この人は悪用可能なバージョンのPHPが動くごく基本的なnginx + php-fpmサーバーを立ち上げて、人々に悪用してみるよう呼びかけるべきだ。