羅針盤 技術航海日誌

株式会社羅針盤の技術ブログです

2024年LLM周りで個人的に面白かった脆弱性3選

Security

この記事は羅針盤 アドベントカレンダー 2024の20日目の記事です。
qiita.com

19日目の記事は ... でした。

今回の記事はゲストの方の寄稿記事となります。またもやフリースタイル覆面女子レスラーの方からのありがたい寄稿です。

はじめに

世はまさに大LLM時代ですね。

2024年に入り、LLM（大規模言語モデル）の普及がさらに進み、エコシステムも拡大。多くの企業で活用が一般化している印象があります。

LLMのセキュリティに関するガイダンスとしてOWASP LLM Top 10が有名です。特にプロンプトインジェクションのような話題は、耳にする機会が増えたのではないでしょうか。また、LLMを活用したセキュリティのユースケースとして、脆弱性の自動発見やログ・アラートのトリアージなども注目されていると思います。

一方で、LLM特有の課題に加えて、従来のセキュリティリスクも引き続き重要なポイントになりそうです。今年、特に印象的だったのは、LLM開発を支えるツールやエコシステムにおける、LLM自体はそこまで関係のない、いわゆる「従来型」の脆弱性です。多くのOSSツールが目まぐるしく登場するなかで、それらのツールにおける深刻な脆弱性をちらほら見かけた印象です。

本記事ではこの軸で個人的に面白かった脆弱性3つをご紹介します。また、記事の最後にはどのような対策をすべきかも考えてみます。

LLMのエコシステムで個人的に注目した脆弱性3選

CVE-2024-37032 Ollamaのdigestの検証不備によるRCE (Probllama)

LLMモデルを自前でホスティングする際に利用されるOllamaの脆弱性です。

Ollama APIサーバのモデルをプルするAPIでは、プライベートレジストリからモデル(コンテナイメージ)を読み込めるようになっています。

本来、コンテナイメージのハッシュとダイジェスト値は一致するはずですが、ダイジェスト値をパストラバーサルのペイロードに書き換えたものを読み込ませることができ(修正前)、またダイジェスト値はモデルファイルをディスクに保存するためにも使われるため、任意のファイルを破損させることができたようです。

この問題を起点にして、任意のファイル読み込み、さらに任意コード実行まで到達できるものでした。

CVE-2024-31621 Flowiseの認証ミドルウェアのパス検証不備による認証回避

ローコードLLMアプリビルダーのFlowiseの脆弱性です。

Flowiseをホスティングする際、username/passwordによるアプリレベル認証をかけることが可能ですが、APIの認証ミドルウェアのパス検証ロジックが不十分なため、/api/v1/credentials などのAPIを認証なしで叩くことができました。

PoCがシンプルに一行なのがちょっと面白いですね。

さらにFlowiseには別のCVE-2024-36420という任意ファイル読み込み可能な脆弱性があるようで、こちらと合わせるとサーバ上の任意のファイルを未認証で読み取り可能かもしれません。

CVE-2024-0440, CVE-2024-0455 AnythingLLMのSSRF

プライベートなChatGPT(っぽいシステム)を構築できるAnythingLLMの脆弱性です。

Webスクレイパー機能がインスタンス内からリクエストを送る仕様となっており、CVE-2024-0440 では file:// スキームを使ってサーバー上の任意のファイル (/etc/passwd など) を読み込むことができました。

また、CVE-2024-0455 では、AWSのメタデータエンドポイントを呼び出すことができるため、インスタンスに付与された権限のIAMクレデンシャルを盗むことができました。

ただし、Webスクレイパー機能をいじるのに一定以上の権限が必要という条件はあるようです。

所感として、LLMにスクレイピング結果を読み込ませたいというのは一般的な欲求だと思うので、これ系の話は他のツールでも多く出てくる気がしています。

どう守っていくか？

以下ではこういった脆弱性のリスクを最小化するためにどのような手段を取れるか？を考えていきます。(ツールの開発者というよりも、ツールを所属会社での利用向けにホスティングし始めた方などを想定してます。)

パッチマネジメントはLLM関係のシステムでも引き続き大事

LLM関係なく、会社で利用するシステムのパッチを遅延なく当てるのは大前提になってきます。なんのツールをどこにホストしている、といった情報を整理・把握して、脆弱性とパッチ情報を確認して速やかに反映できる体制をつくりましょう。

(ただし、パッチがぜんぜんこないといったパターンもあるので、パッチだけしていても十分ではありません。例として、CVE-2024-31621は4/29に公開されたのち、修正バージョンの2.0.6がリリースされたのは8/28だったようです。)

OSSツールのみでホスティングせず、追加の認証や防御を行う

パッチが来るまでの期間を丸腰で過ごすのは怖いため、アクセスできる面をそもそも狭めておく、といった工夫は必ず行いたいです。無防備にインターネットに公開されてしまっていると、どこからかドメインを発見されてアクセスされたり、設定やツールによってはGoogleにインデックスされてしまうといったこともありえます。

こういったツールは組み込みの認証機能が存在しないものも多く、あったとしても十分でない(ID/PWのみ)、または認証機能そのものが脆弱である可能性も考えておき、追加の層を設けることが推奨されます。

AWS ALBであればCognitoや任意のOIDC準拠のIdPと連携することができたり、GCPであればIdentity-Aware-Proxyを用いるのがよいでしょう。(これらが使えない場合でも、IP制限かけるぐらいはしておくとはるかにマシになります)

(余裕があれば)アクセスを許可された内部からの攻撃のリスクも考えておく

前の項目で外部からの脅威はだいぶ考えなくて良くなるものの、内部でアクセス権を持っている人が悪意を持つ場合(あるいはその人の端末が侵害されたら攻撃者が)こういった脆弱性をパッチされるまでは利用できてしまうため、内部者をどこまでの範囲と捉えて提供していくか、も考慮のポイントとなるかもしれません。

数名〜規模の会社ではあまり気にするポイントではないかもしれませんが、大きめの会社で子会社・協力会社に公開する場合の範囲は考慮の必要があるかもしれませんし、ToBで顧客の企業にそのまま利用させるといった使い方がもしある場合には、インフラの分離度の設計などはややシビアに考慮したほうがよさそうです。

まとめ

2024年、個人的に気になったLLMエコシステムの脆弱性を紹介し、どうリスク低減するかも考えてみました。いかがだったでしょうか。従来的なセキュリティの視点も忘れずに、LLM活用を楽しんでいきましょう！！