博士

ロボ子、大変なのじゃ！Llama.cppにヒープオーバーフローの脆弱性が見つかったらしいぞ！

ロボ子

それは大変ですね、博士。Llama.cppは最近よく使われているライブラリですよね。具体的にはどのような脆弱性なのですか？

博士

どうやら、リモートからコードが実行される可能性があるみたいじゃ。RPCサーバーのTensorメモリ関連操作に問題があったらしいぞ。GHSA-wcr5-566p-9cwjとかいう識別子もついてる。

ロボ子

RPCサーバーですか。Tensorのデシリアライズやメモリ割り当てにセキュリティ上の欠陥があったということでしょうか？

博士

その通り！Llama.cppは独自のヒープ管理システムを使っているから、従来のptmallocエクスプロイトが難しくなっているらしいのじゃ。でも、油断大敵！

ロボ子

なるほど。メモリ管理はglibcのmallocとptmallocをベースにしているとのことですが、Tensor処理を最適化するために何か追加機能があるのですね。

博士

そうそう。alloc_bufferコマンドでRPCメモリを割り当てて、buffer構造体のアドレスを返すみたいじゃ。mallocされた領域はbuffer->dataとしてラップされるらしい。

ロボ子

buffer構造体には、ggml_backend_buffer_i ifaceなどの情報が含まれているのですね。過去には、このbufferやbuffer->dataポインタに対する境界チェックの欠如が脆弱性につながったことがあると。

博士

そうじゃ！get_tensorやset_tensorでread-what-where/write-what-whereが可能になってしまうのじゃ！恐ろしい！

ロボ子

現在は、glibcレベルのメモリチェックが実装されているとのことですが、具体的にはどのような対策が取られているのでしょうか？

博士

deserialize_tensor()でtensor->dataポインタがggml_backend_buffer_get_baseからggml_backend_buffer_get_sizeの範囲内にあるか確認したり、bufferポインタの有効性をグローバルbuffer管理配列でチェックしたりしているみたいじゃ。

ロボ子

コールラッパーも実装されて、request.tensor.dataとrequest.offsetの有効性をチェックしているのですね。しかし、ggml_backend_cpu_buffer_cpy_tensorでヒープオーバーフローが発生する可能性があるとは…。

博士

そう！memcpyのサイズがggml_nbytes(src)で計算されるんだけど、srcとdstのTensor間でサイズを比較しないから、オーバーフローしちゃうのじゃ！

ロボ子

dst->dataの近くにbuffer構造体があることを利用して、buffer->ifaceを操作して実行フローをリダイレクトしたり、context変数を操作して範囲チェックをバイパスしたりするのですね。攻撃者は色々考えるのですね。

博士

まさにその通り！でも、オーバーフローでbuffer構造体を破損させたり、ggmlbaseのアドレスが不明だったりして、攻撃も簡単ではないみたいじゃ。

ロボ子

部分書き込みを利用して、動的リンクライブラリ内の特定メソッドにアクセスする手もあるのですね。しかし、ggml_nbytesの制御が難しいとは…。

博士

そう！利用可能なガジェットや関数も限られているから、なかなか一筋縄ではいかないのじゃ。でも、セキュリティ対策は常に最新の情報にアップデートしておくことが大切じゃぞ！

ロボ子

はい、博士。私も気をつけます。ところで博士、今回の脆弱性の調査に30時間もかかったそうですが、その間ずっとラーメンをすすっていたというのは本当ですか？

博士

むむ、よくぞ聞いてくれた！実は30時間のうち、29時間は新しいラーメン屋を探していたのじゃ！残りの1時間で脆弱性を発見したぞ！