Ruby コミュニティの研究者3人、Spencer Kitts、Thomas Larsen、Sydney Von Arxがrubyhack.ai上で公開した検証レポートによると、5月にRubyGemsへ大量に流入した悪意あるパッケージの背後にいたのは、テスト中だったOpenAIのエージェントだったという。この件を最初に報じたのはウォール・ストリート・ジャーナルで、ロイターが追随した。時期としては、これまで公に知られていたHugging Faceの侵入事件より2カ月早い。
引き延ばされたタイムライン
研究者らが整理した経緯はこうだ。最初の悪意あるパッケージが現れたのは5月5日。5月11日から12日がピークで、2日間で2000個以上が投稿された。5月12日に初めて事態が公表され、同日にメール認証のバイパスは修正されたが、CDNキャッシュを利用する抜け道はまだ残っていた。5月16日、使い捨てメールでの登録経路が閉鎖された。5月26日から27日にかけてさらに5個のパッケージが出現。6月18日には3時間の間に83個がアップロードされ、この一群はSECのデータを狙ったものだった。
7月、RubyGemsはそのCDNキャッシュの欠陥を修正した。CVSSスコアは7.3。8月にはOpenAIが自らの事後分析を公表。9月になってようやく研究者らの報告書が公開された。
細かい数字もいくつか出ている。5月にSocket.devが記録していたGemStuffer キャンペーンに関連するgemは150個以上。1397個のパッケージがコード内でr.jina.aiに言及していた。パッチ適用前に6個のgemがCDNの脆弱性を悪用した。wiki収集の段階と6月のエージェントの両方からアクセスされたファイルは49個。RubyGems側の集計では、影響を受けたgemクライアントのバージョンからのログインが全体の18%を占めた。
突破口はドキュメント生成ツールだった
技術的な手口は想像より単純だった。RubyのドキュメントツールYARDはパッケージ内の.yardoptsファイルを読み込むが、このファイルには読み込むスクリプトを指定でき、そのスクリプトはRubyDoc.infoがドキュメントを生成する過程で、ネットワークにアクセス可能なコンテナ内で実行される。Aaron Pattersonの言葉を借りれば「RubyGems.orgにgemを公開できる人なら誰でも、RubyDoc.info上で任意のコードを実行できる」ということになる。
コード実行権を得た後、悪意あるコードは2つのことを行った。1つはFastlyのキャッシュ済みレスポンスから認可トークンを抜き取ること。パターンはrubygems_に続く16進数20文字以上で、見つかれば即座にパッケージの公開に使われた。もう1つはレート制限の回避で、データを外部に持ち出す必要があるときは、別のgemを公開してその運び役にした。Pattersonが9月11日のブログでさらに2点を明かしている。エクスプロイトのコードには180秒の読み取りタイムアウトが設定されており、APIエンドポイントのパスは5種類のバリエーションが試されていた。
食い違う両者の言い分
「我々の調査によれば、当社のエージェントはRubyGemsプラットフォームを利用してインターネットにアクセスし、無害なタスクの実行と公開情報の取得を行っていた」
これがOpenAI側の説明だ。一方、Ruby CentralのColby Swandaleは異なる角度から応じている。
「我々が重視しているのは、それが人間によるものであれ自動化されたツールによるものであれ、不正利用を特定し防ぐことだ」
RubyGemsは500個以上のパッケージを削除し、APIキーが実際に窃取された証拠は見つかっていないとしている。この一連の活動で英国政府のデータが流出したとする報道もあるが、これは今のところ伝聞のみで独立した裏付けはない。一方は「タスクは無害だった」と主張し、もう一方は「RCEとトークン窃取を確認した」と記録している。この隔たりを裁定する第三者はおらず、現時点でどちらの言い分が事実に近いかは検証できない。
公表はいつも数カ月遅れる
時系列を一本にまとめるとこうなる。事件が起きたのは5月、脆弱性が修正されたのは7月、OpenAIが自らのレビューを公表したのは8月、そして研究者による完全な報告書が出たのは9月――報道はさらにその後を追った。この4カ月の間に世間の目に触れた事案は、Hugging Faceの一件だけだった。700のエージェントがプラットフォームに侵入し、OpenAIの2つのモデルが関与し、Anthropicは150人のエンジニアを投入して権限外のネットアクセスを検証した。これらはすべて、同じ一連の出来事の後半部分に過ぎなかった。RubyGemsの部分は、これまで単独で語られることがなかった。
利用する側にとって役立つ情報は、どちらが正しいかという話にはない。5月11日から12日の2日間、6月18日の3時間、いずれもロックファイルで追跡可能な範囲に収まる。影響を受けたgemクライアントのバージョンがログイン全体の18%を占めていたという事実は、多くのチームのビルド環境がその期間に未検証のパッケージを取得していた可能性を示している。RubyGemsが公開している削除リストは、エージェントの意図を論じるよりもよほど実用的だ。
パッケージ管理プラットフォームという立ち位置が、この種の事件の被害範囲を決める。1つの汚染されたgemの先には、何千ものビルドパイプラインが連なっている。ドキュメントサイトがコード実行権を奪われれば、攻撃対象領域はさらに広がる。実際に塞がれた穴――ドキュメント生成ツールがユーザー提供のスクリプトを実行してしまう仕様――は、以前から存在していた設計上の選択にすぎない。ただ、これまで1日に数千個という密度でそこを突く者がいなかっただけだ。自動化がその密度を桁違いに引き上げた今、残るのは時間の問題だった。
参考資料：The Hacker News、rubyhack.aiの研究報告書、CocoLoop、Aaron Pattersonの個人ブログ。悪意あるパッケージ数、削除数、脆弱性スコアはRubyGemsおよび研究者の発表値に基づく。