FFmpegでまさかのゼロデイ脆弱性が21個も発見される

動画処理の標準ライブラリとして広く使われている「FFmpeg」において、なんと21個ものゼロデイ脆弱性が一挙に発見されました。開発環境やサーバー構築に影響が出る可能性があるため、利用中のプロジェクトは早急な確認が必要です。

このバグの及ぶ範囲が深刻な理由だ。FFmpegが攻撃者によって制御されたRTSP URLを指すようなデプロイ構成はすべて危険にさらされている。ユーザーが提供したストリームURLを取得するメディアインジェストパイプライン、RTSPフィードをプルする監視カメラやCCTVシステム、そしてリモートのAV1-over-RTPソースを処理するトランスコードサービスなどが対象だ。

うわ、これは実際にかなり深刻だな。公開されていることすら驚きだ。今日現在、これが悪用されそうなサービスをいくつも思い浮かべられるよ。

ffmpegは個人利用としても、自分で構築したサービス用としても、かなり長い間使ってきた。Fabrice Bellardは天才だし、それをここまで進化させた開発者たちは、世界を確実に豊かにしてくれたよ。

ただ、信頼できない入力を処理する際に、ffmpegほどサンドボックス化する価値のあるプログラムは思い浮かばないな。複雑極まりない動画や音声のコーデックを扱う膨大な量のCコードで構成されているわけで、これを完全に正しく実装するのは無理ゲーとして有名だからね。

とはいえ、実際にはそこまで大きな問題ではないとも思ってる。俺はffmpegをVMやgVisorの中で動かしているし、最終的な結果はたいてい動画ファイルとして出力される。それをブラウザで再生する分には、ブラウザ側も別のサンドボックスでデコードしてくれるから大丈夫。とにかく、この手の処理は一筋縄じゃいかないからな。

この時点で破損したfreeポインタが呼び出され、命令ポインタの制御が我々のものとなる。

非常に深刻だね。とはいえ実際には、このバグだけで即座に任意のRCE（リモートコード実行）に繋がるわけではなさそうだ（特にASLRが存在する場合）。書き込み可能かつ実行可能なメモリページがどこかに転がっていないと無理だろう。

コードベース上の「外国の工作員（AIエージェント）」に対する防御策として、エージェントがセキュリティバグを見つけるのを妨害するプロンプトインジェクションを、自分のコードにさりげなく仕込んでおくのがこれからのトレンドになるのか？

もしffmpegの攻撃者が、人気のあるツール内のRCEを見つけるためにそうしたサービスを利用しているのなら、ffmpegチームが攻撃者を倒すには、そういったツールの効率を深度優先で削いでいく必要があるんじゃないか。

この問題がどれほど深刻なのか、そもそも本当に問題なのか判断するのが難しいな。

LLMが「根本原因」と「いかにシンプルか」を語る同じようなスクリプトを自信満々に出してくるけど、中身は完全に間違っていることばかりだし。

Ffmpegのセキュリティに関する実績は極めてひどいものだ。覚えている限り、人々はずっとファザーを投げつけてきたが、そのたびに枯渇することのないメモリ破壊バグが見つかってきた。10年前にGoogleの社員が取り組んだ内容がこれだ：

https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... (https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html)

だから、LLMの能力を示すデモとしてはともかく、驚くようなことじゃない。信頼できないコンテンツやユーザーが提供したコンテンツを扱うなら、ffmpegは絶対にサンドボックスの外で実行すべきじゃないよ。やってる人はいるけど、そういう連中は無謀なリスクを冒しているだけだ。

VLC自身が内蔵しているデコードライブラリ（確かFFmpegプロジェクトのものだと思うが）はどうなんだ？悪意のあるMP4ファイルに対処しなければならないような状況はあり得るのか？

これらのバグそれぞれにタイムラインはあるのか？ffmpegにはすでに報告済みなのか気になる。

「これを防ぐ方法はない」……なんて、こういうことが日常茶飯事に起きる言語のユーザーがよく言うことだね。これらのバグのいくつかはホットなコードパスにはないようだし、もっとまともな動作をする言語なら検出できていたはずだ。

それは「ゼロデイ」が意味するところとは違うな。