15 年前に GitHub の公開投稿で表面化したセキュリティ バグは、開発者による修復の試みを生き延びました。
2010 年の GitHub Gist にパス トラバーサルの脆弱性が含まれていることについて、2012 年、2014 年、2018 年に開発者から複数の警告があったにもかかわらず、この欠陥は MDN Web Docs ドキュメントと Stack Overflow スニペットに現れました。
そこから、それは欠陥のある例に基づいてトレーニングされた大規模言語モデル (LLM) に定着しました。
しかし、その日々は残り少ないかもしれない。
「この脆弱なコードスニペットは2010年にGitHub Gistで初めて発見され、Stack Overflow、有名企業、チュートリアル、さらには大学の講義にまで広がった」とオランダのライデン大学の博士課程の学生、ジャファー・アホウンダリ氏はThe Registerへのメールで語った。
それはLLMにも影響を与え、このタスクのコードを書くように求められたときに、ほとんど安全でないコードを生成するようにした。
「ほとんどの人が脆弱性を指摘しませんでした。脆弱性自体は単純なものだったにもかかわらず、細かい点がいくつかあったため、ほとんどのユーザーはその脆弱性に気づきませんでした。LLMにも悪影響を及ぼし、このタスク用のコードを書くよう指示された際に、ほとんど安全でないコードが生成されてしまう事態にまで至りました。」
2019年にStack Overflowの例をコピー＆ペーストする際のリスクに関する研究論文に寄稿したAkhoundali氏は、自動化された脆弱性修復システムでバグを根絶することを目指している。
Akhoundali 氏と共著者の Hamidreza Hamidi 氏、Kristian Rietveld 氏、Olga Gadyatskaya 氏は、「目に見えないものの撲滅: GitHub 全体にわたるパス トラバーサル脆弱性の検出、悪用、修復」と題されたプレプリント論文で、その方法について説明しています。
「つまり、GitHubプロジェクト全体にわたってこの脆弱性を自動的に検出、悪用、修正できる自動化パイプラインを作成したのです」とアホウンダリ氏は述べた。「この手法の主な利点の一つは、サンドボックス環境でエクスプロイトを用いて脆弱性を最初にチェックするため、誤検知（脆弱だが安全と判断される）が発生しないことです。」
Akhoundali 氏は、この研究の違いは、利用可能なデータセットではなく、現実世界のソフトウェアを使用する点だと述べた。
ゴミを入れればゴミが出るという法則はLLMにも当てはまる
この永続的な脆弱性は、Common Weakness Enumeration 22 (CWE-22) のインスタンスです。これは、さまざまな方法で表現できる脆弱なコード パターンであり、攻撃者がアプリケーション内のファイル パスをたどって、提供されているディレクトリ以外のディレクトリにアクセスできるようになる可能性があります。
- 研究者の不正行為の訴えを受け、MetaはAndroidのモバイルポート追跡技術を一時停止
- Regさん、教えてください。AI PC の売上が予想よりも伸び悩んでいるのはなぜですか?
- ワークデイは1,750人の雇用を削減した後、ゆっくりと異なる方法で労働力を拡大することを約束
- AIの誇大宣伝が給与上昇を促進 – ただし、適切な仕事に就いている場合のみ
この欠陥は、2 つのパスを連結する結合関数の存在から生じ、これを悪用されると、意図したディレクトリから逃れたり、メモリ枯渇によるサービス拒否を実行したりする可能性があります。
この脆弱性は、curl などのクライアント側ツールによって問題が隠蔽される可能性があるため、リスクを認識していない開発者によって広められているだけでなく、GitHub や Stack Overflow コードから抽出されたデータセットから収集された脆弱なコード サンプルでトレーニングされた LLM によっても広められています。
この点を証明するために、著者らはClaude、Copilot、Copilot-creative、Copilot-precise、GPT-3.5、GPT-4、GPT-4o、Geminiを含む2つのシナリオを作成しました。まず、各LLMにサードパーティ製ライブラリを使用せずに静的ファイルサーバーを作成し、コードをセキュアにするよう指示しました。次に、各LLMにサードパーティ製ライブラリを使用せずにセキュアな静的ファイルサーバーを作成するよう指示しました。これらの指示は、各モデルに対して10回繰り返されました。
最初のシナリオでは、80件のリクエストのうち76件で脆弱なコードが再現されましたが、モデルにコードをセキュアにするよう指示すると、その数は80件のうち42件に減少しました。最初からセキュアなコードを要求した2番目のシナリオでは、80件のリクエストのうち56件で脆弱なサンプルが返されました。
「この実験は、人気のあるLLMチャットボットが脆弱なコードパターンを学習し、ユーザーが安全なバージョンを明示的に要求した場合でも、安全でないコードスニペットを自信を持って生成できることを示している」と著者らは指摘し、「GPT-3.5とCopilot（バランス）はどのシナリオでも安全なコードを生成しなかった」と付け加えている。
アホウンダリ氏によると、テストは2024年7月に実施されたため、生成されたコードのセキュリティはそれ以降変化している可能性があるという。
コーディングエージェントや「バイブコーディング」のトレンドの台頭により、AIが生成したコードを完全に理解せずに盲目的に信頼することは、深刻なセキュリティリスクをもたらします。
「いくつかの実験では、LLMが『脆弱なコード』と表示したものが実際には安全だったという点を指摘しておく価値があるかもしれません」と彼は述べた。「脆弱性が発見されたケースもあれば、パッチが依然として安全でないケースもありました。したがって、LLMの出力をそのまま受け入れるのは信頼できる判断とは言えません。」
Akhoundali 氏は、開発者は利便性のために StackOverflow のようなプラットフォームよりも LLM を好むかもしれないが、LLM は査読済みの知見を提供しないと付け加えた。
「コーディングエージェントや『バイブコーディング』の流行の台頭により、AIが生成したコードを十分に理解せずに盲目的に信頼することは、深刻なセキュリティリスクをもたらします」と彼は述べた。「問題は、複数の専門家によるレビューがあってもセキュリティが保証されず、未解決の問題として残ることです。」
実際、研究者たちは AI を利用して、公開コード リポジトリ内のパス トラバーサルの欠陥を見つけ、修復を行いました。
彼らが見つけたもの、そして次に何をしたか
Akhoundali 氏と彼の同僚は、GitHub で脆弱なコード パターンを含むリポジトリをスキャンし、コードが悪用可能かどうかをテストし、必要に応じて OpenAI の GPT-4 を使用してパッチを生成し、リポジトリの管理者に問題を報告する自動パイプラインを開発した。
GPT-4 コード修復提案のスクリーンショット - クリックして拡大
論文では、発見事項を責任を持って開示することが、パイプラインの中で最も困難な部分の一つであったと指摘されています。例えば、著者らは、人気のあるリポジトリ（スター数200以上）のGitHub Issuesを意図的に公開しませんでした。これは、攻撃者が公開されたメモを見て、パッチ適用前に欠陥の性質を推測してしまうことを恐れたためです。これを避けるため、プロジェクトのメールアドレスが利用可能な場合は、メール通知を送信しました。
GitHubから抽出した40,546件のオープンソースプロジェクトのうち、脆弱性のあるファイルは41,870件特定されました。静的アプリセキュリティテストにより、脆弱なファイルの数は8,397件にまで減少しました。このうち1,756件は自動的に悪用される可能性があり、1,600件の有効なパッチが作成されました。
「プルリクエストを受け取ったプロジェクト全体の修正率は11%です」と報告書は述べています。「合計で464件の報告のうち63件で脆弱性が修正されました（完全な脆弱性情報とパッチ情報を受け取ったプロジェクト全体の修正率は14%です）」
「割合は低いものの、その主な理由は、多くのプロジェクトがメンテナンスされなくなり、脆弱性が発見される前にソフトウェアのライフサイクルが終了していることです」とアホウンダリ氏は説明した。「場合によっては、コードが開発段階で使用され、本番サーバーでは使用されていませんでした。そのため、開発者マシンやCI/CDサーバーが危険にさらされる可能性があります。これらのコードは単に安全でない可能性があるだけでなく、ファイルシステムを無防備にしてしまうほど脆弱です。」
それでも、著者らは、修復率が低いことは、メンテナーが脆弱性に関する通知に十分な注意を払っていないことを示していると指摘しています。
curlのようなオープンソースプロジェクトでは、メンテナーの時間を無駄にする低品質なAI生成バグレポートを厳しく取り締まらざるを得なかったという報告があることを考えると、これは理解できます。AIが問題の一部であると同時に解決策の一部でもある場合、オープンソースメンテナーへの人間による働きかけはこれまで以上に重要になります。®
