OpenAI、Slack、Meta、GitHubの下に同じ画像ライブラリがある。それを破るのに要したのはモデルの3時間だった

Hacktronの3人の研究者は、この夏、一本の糸を引き続けた。HEIC、HEIF、AVIFのファイルをピクセルに変換するオープンソースのCライブラリ、libheifである。今週、彼らはその糸をたぐった先にあったものを公開した。同ライブラリのデコード処理に存在するヒープバッファオーバーフローによって、彼らはOpenAIのコミュニティフォーラム上でリモートコード実行を獲得し、そこからOpenAI従業員のChatGPTおよびCodexアカウントへ、さらにそれらのアカウントに接続されたGitHubリポジトリへと到達した。同種の欠陥はSlack、Meta、GitHub Enterprise Server、Discourse、Next.jsにも及んだ。

いずれも修正済みである。本題はバグそのものではない。

誰も書き留めない依存関係

ユーザーがアップロードした写真を受け付けるプラットフォームは、ほぼ例外なくそれをデコードしなければならないが、自前でデコードしているところはほとんどない。バイト列はネイティブライブラリに渡され、HEICとAVIFの場合、そのライブラリはたいていlibheifであり、実際のHEVCデコードはさらにlibde265に委ねられる。製品紹介ページに名前が載ることはなく、脅威モデルに現れることもまれで、多くのスタックでは画像処理ライブラリやサムネイル生成サービスを介して3層も4層も下に取り込まれている。

上流のアドバイザリ GHSA-g89c-p67h-r497 は深刻度を9.8と評価し、条件を明快に述べている。細工されたHEIC、HEIF、AVIFファイルが、通常のデコード呼び出しの過程でヒープバッファオーバーフローを引き起こす。認証も、ユーザー操作も、特殊なAPI設定も不要だ。信頼できない画像をデコードするアプリケーションはすべて対象となる。このアドバイザリには固有のCVEが割り当てられていない——「CVEがある」ことが「追跡されている」ことの代わりにはならない、という戒めである。

影響を受ける一覧が、一社の顧客リストではなく現代のウェブの名簿のように読めるのはそのためだ。

何を適用すべきか

自社で運用しているものがこの一覧にあるなら、やるべきことはバージョン番号がすべてだ。自前の画像処理パイプラインを持っているなら、問うべきは、どのサービスが気づかぬうちにlibheifを呼び出しているか、そしてそのデコードがサンドボックス内で行われているのか、それともアプリケーションのプロセス内で行われているのか、である。

14時間と6,500ドル

研究者の報告におけるOpenAIの時系列は異例なほど具体的だ。7月23〜24日、Discourse経由で到達可能なlibheifにオーバーフローを特定。7月25日の朝には community.openai.com でコード実行を得ていた。数時間以内にOpenAIのBugcrowdプログラムを通じて報告し、その後、従業員アカウントを乗っ取り、OpenAIの内部コードベースにプルリクエストを作成して影響を実証した。OpenAIは同日22:49 UTCに修正を確認——報告から14時間以内である——Discourse上流と連携し、9月1日に6,500ドルの報奨金を支払った。

この対応こそ、本件でうまく機能した部分だ。フォーラムは、誰も本番環境とみなさないがゆえに実質的なアクセス権を蓄積していく、典型的な「格下の隣接資産」である。OpenAIはそれを本番環境として扱った。

重要なのは3時間

画像パーサーのメモリ破壊バグは新しいものではない。ファジングは20年にわたってこの種の不具合を発見し続けてきた。これまでそれを抑制してきたのは、クラッシュを見つけるのは安価でも、そのクラッシュを堅牢化された現代の標的に対する確実なエクスプロイトへ仕立てる作業は高価で、希少な専門性を要するという事実だった。この隔たりがあったからこそ、この種のバグの多くは静かに修正され、武器化されることはなかった。

研究者は、その隔たりが消えたと述べる。彼らの説明によれば、標準的なメモリ保護が有効な状態で動作するエクスプロイトを、Claude Opus 4.8は複数のセッションにわたって作れなかった。リリースから数時間のうちにOpus 5へ同じ問題を与えたところ、約3時間で作り上げ、研究者はそれを標的が動作するアーキテクチャ向けに移植した。プロジェクトページでは、フロンティアモデルを用いたエージェント的な手法により、最初の探索からリモートコード実行までのエクスプロイト開発期間がおよそ1〜3日に圧縮されたと説明している。

結論は彼ら自身の言葉にある。

AIは、その希少な専門性をより多く計算資源に置き換えることで、この保護を取り払いつつある。かつては潤沢な人員を抱えるチームと数か月の労力を要した作業が、いまや数日に圧縮されうる。

これらは研究者が自らのツールについて述べた主張であり、そのように読むべきだ。しかし裏づけは修辞ではない。7つのプラットフォームでの修正、GitHubでのCVE採番、支払われた報奨金、そして実証済みの影響を伴って届いた報告ゆえに1日足らずで投入された修正である。

防御側が受け取るべきもの

実務上の教訓は、AIについてのものではまったくない。未適用の依存関係をめぐる経済性が変わった、ということだ。自社が出荷していることすら知らなかったパーサーのメモリ安全性のバグは、これまでは長いリストに並ぶ理論上のリスクだった。「どうせ誰も武器化する手間はかけない」という前提は、いまやその論法の最も弱い環であり、たいていのバックログ選別が暗黙に頼っている前提でもある。

libheifを1.23.2に更新すること。そのうえで、スタックの中で信頼できないバイト列をCで解析しているものが他に何かを突き止め、それが封じ込め可能な場所で行われているかを確認することだ。

出典: Hacktron: Hacking OpenAI · HEIF Heist · libheifアドバイザリ GHSA-g89c-p67h-r497 · Forbes: Security Researchers Hacked Into OpenAI Using Anthropic's Claude