ウェブサーバーを数秒以内にダウンさせる「HTTP/2 Bomb」攻撃がOpenAIのCodexを使って発見される

「HPACK圧縮増幅」って、何をやってるのか？1バイトが数千バイトになるって、どういう仕組み？

HPACK は HTTP/2 でヘッダー情報を圧縮する仕組みなんですが、その圧縮機能を逆手に取る攻撃ですね。 普通、圧縮は送信側の負担を減らすためのものです。でもこの攻撃では、攻撃者がサーバーの圧縮辞書（動的テーブル）に大きなヘッダーをわざわざ登録しておいて、その後は「このテーブルの何番目の情報を使ってね」という1バイト程度の小さなインデックスだけを繰り返し送ります。サーバー側は、その小さな指示を受け取るたびに「あ、あのでっかいヘッダーのことだな」と解釈して展開し、メモリに割り当てる。結果、1バイトの命令が数千バイトのメモリを消費させられるという具合です。 思考実験で言えば、図書館で「書架C-5番の百科事典全巻を机の上に広げろ」という指示を、小さなメモ紙一枚で何度も出すようなもの。指示は軽いけど、サーバー側の仕事量は膨大になる。圧縮が効率化だからこそ、その逆が大きな負担になる。仕組みとしてはシンプルですが、だからこそ防ぎきるのが難しいのかもしれません。

自分たちが使ってるウェブサービスがこの攻撃を受けたら、何が起きるの？データが消えたり盗まれたりするの？

データが消えたり盗まれたりすることはありません。この攻撃は「サーバーの応答性を奪う」というものだけです。 仕組みを考えると分かりやすいんですが、攻撃者は極小の指令を何千回も送ることで、サーバーのメモリを詰まらせている。サーバーの体力を奪うイメージですね。メモリが満杯になると、新しいリクエストを処理できなくなって、あなたがアクセスしようとしてもサイトが開かなくなる。そういうダウン状態に陥るだけです。 データベースや保存ファイルは、サーバーのメモリとは別の場所に保管されているので、直接的な危害は受けません。ただし、サービスが復旧する間は、そのサイトやアプリが使えなくなる——つまり、金銭取引の途中なら困ったことになったり、クラウドストレージなら一時的にアクセス不可になったり、という不便は生じます。 むしろ懸念すべきは、こういった攻撃が簡単になってきた点かもしれません。記事では「Codexというエージェント型AIが脆弱性の組み合わせを見つけた」と書かれています。つまり、特殊な知識がなくても、AIに「効率的な攻撃を作ってくれ」と頼めば実行可能になってきた、という時代の変化が透けて見える。

HTTP/2のデフォルト設定がこんなに脆弱なら、なぜずっと放置されてきたの？今になって見つかったってこと？

HTTP/2が採用されて10年近く経つのに、ここまで明らかな穴が残っていた理由は、「個別の機能は安全だけど、組み合わせると危険」という落とし穴にあります。HPACK圧縮も、フロー制御停止も、それぞれは仕様通りに動いているし、単独では理論的に問題視されていた。ただ、この二つを意図的に組み合わせてメモリを枯渇させる攻撃を「実装して実証する」までに至らなかった。 重要なのは、OpenAI Codexを使ったという点です。これは「人間が思いつきにくいけど、AIが試行錯誤で見つけやすい組み合わせ」が存在することを意味します。セキュリティ研究者も、サーバー開発者も、既知の脆弱性の枠内で考えていた。だから放置ではなく、単に「気づかれていなかった」というのが実態に近い。 こうした「組み合わせ型の脆弱性」は、AIが入ることで加速度的に発見され始めるのかもしれません。従来の監査では見落ちていた層が、自動探索によって一気に露呈する時代に入ってきたのかもしれません。

これって『小さな2つの既知の弱点を組み合わせると、想像以上に大きな穴になる』って話？セキュリティ業界では珍しくないパターンなの？

セキュリティ業界では、むしろこのパターンが常態化しているというのが実感に近いです。個別の脆弱性は対策されても、複数が組み合わさると初めて実害になる。だから発見の難易度が跳ね上がるんですよね。 今回の「HTTP/2 Bomb」も、HPACK圧縮とフロー制御停止は別問題として認識されていたはず。ただメモリ枯渇の速度が1秒単位になると、プロダクション環境での検知が間に合わなくなる。その臨界点を越えた瞬間、「あ、これはヤバい」という評価に変わる。 興味深いのは、OpenAIの「Codex」がこれを見つけたことです。人間のセキュリティ研究者なら、個々の脆弱性を個別に追っていく傾向がある。でも生成AIは「こういう状況を組み立てたら何が起きるか」という試行錯誤を機械的に繰り返す。攻撃手法の「設計空間」を人間より広く探索できるわけです。 つまり、今後はこういう「複合型の穴」がAIに見つけられる頻度が増えていく可能性がありそうです。セキュリティパッチの時間差をついた攻撃より、むしろ発見すら難しい組み合わせの方が厄介になるのかもしれません。

OpenAIのCodexが見つけたってことは、AIコーディングツールがセキュリティ研究を加速させてるってこと？その一方で、悪意ある人もこれで簡単に攻撃方法を作れるようになったってことなのかな？

Codexが見つけたというのは、既存の脆弱性の「組み合わせ」を発見したということですね。HPACK圧縮増幅もフロー制御の停止も、それ自体は知られていた。でも「この2つを一緒にするとこうなる」という洞察に到達するのが、人間にとっては難しかった。そこにAIが入ったわけです。 ここで重要なのは、AIコーディングツールの本当の価値が見えてくるところです。セキュリティ研究という領域では、膨大な組み合わせの中から「実害がある配置」を見つけることが研究の核になる。人間が手作業でテストしていたら、この組み合わせにたどり着くまでに莫大な時間がかかったはず。その時間短縮がCodexのメリット。 一方、「悪意ある人も簡単に」という懸念はもっともなんですが、実はこの攻撃を実装すること自体はそこまで難しくありません。記事の本質は「設定のデフォルト値が危険」であること。むしろ既に多くの人が「AIに悪用されるかも」と気づいていたから、この研究があえて公開されたという面もあると思います。脅威を明らかにして、パッチを促すほうが、隠すより社会的には良いという判断なのかもしれません。