この記事の途中に、以下の記事の引用を含んでいます。
Autonomously Finding 7 FFmpeg Vulnerabilities With AI
暗闇に埋もれたバグをAIが発掘!? FFmpegのセキュリティ最前線
動画や音声の処理に欠かせないオープンソース・ソフトウェア「FFmpeg」。
世界中のアプリやサービスで標準コンポーネントとして利用されているこのソフトですが、その内部には従来手法では発見が難しい“論理的バグ”が潜んでいたことをご存じでしょうか。
今回紹介するブログ記事「Autonomously Finding 7 FFmpeg Vulnerabilities With AI」では、ZeroPath社のAI駆動セキュリティツール（AI SAST）がFFmpegのコードから7件もの新手のバグ（主にメモリ安全性の問題）を自動発見した経緯を詳細に取り上げています。
この記事では、その手法・発見内容・伝統的手法との違い、さらには今後の開発現場やセキュリティへの波及効果まで、専門的視点から解説します。
バグはこう見つかった！記事の主張とAIセキュリティ解析の衝撃
まず、記事の冒頭には次のように書かれています。
“ZeroPath’s AI-assisted SAST analyzed FFmpeg’s protocol handlers, parsers, filters, and Android glue code, and reported seven distinct memory safety flaws. Each issue stems from a mismatch between what the developers intended to guarantee and what the code actually does. This is precisely the class of issues that traditional SASTs miss: subtle, logically-flawed code, that cannot be detected with simple pattern matching.”
要点は「開発者の意図と実際の挙動の不一致」から生じる論理的なバグこそ、従来の静的解析（SAST）が見逃しやすいものであり、AI型SASTだからこそ検出できた、という点です。
「論理的な不一致」とは、例えばバッファサイズの計算方法や、メモリ割当とコピーの整合性チェックなど、2～3関数をまたぐ設計レベルのバグです。
ルールベースで「NGワードがあったら」といった従来型スキャナでは検出できないタイプなのです。
なぜAIにしか見つけられなかった？解くべき謎の本質
伝統的な手法の限界
記事では各脆弱性の詳細を踏まえ「なぜ従来ツールでは見逃したか？」も解説されています。
たとえば次のような言及があります。
“Division-based truncation does not look suspicious locally; the copy uses a variable that appears ‘validated’ by earlier code.”
これは「整数除算による丸め落とし」のような一見安全そうに見えるコード断片が、後続処理で重大なメモリ破壊につながっている例です。
一般的なツールやレビューでは、こうした“ローカルに問題なさそう”な部分を超えて、プログラム全体の「意図」の齟齬までは把握できません。
AI SASTの手法と強み
ZeroPathのAI SASTが注目すべき点は“論理モデルの構築による検証”です。
例えば「Aから導出されたサイズでバッファを確保し、その後Bバイトコピーする場合、B<=Aでなければならない」という契約を自動的に構築します。
さらに実例（テストベクトル生成）で「等しくならない場合」の反例を示し、実害有無まで証明します。
このアプローチは、従来の「禁止パターン検出」や「単純範囲外アクセスチェッカー」と根本的に異なります。
複雑なパスや例外処理、異常な引数値、極端な動画パラメータなど「人間も見落としやすい」論理的欠陥をもれなく発見可能です。
“見逃されていた7つの実例”から見える現場課題
では、具体的にどういうバグが見つかったのか？
以下は記事の7件の分類と、その背後にある共通課題です。
1. Android MediaCodecのバッファオーバーフロー
丸め落としによりバッファサイズの過少確保→memcpyで溢れる問題です。
分母がexactでない場合（たとえば25/10=2.5だが2が代入される等）「割り算のあまり」が見逃され、memcpyが過剰に書き込む状態に。
Android端末からの攻撃パスが成立します（しかもネット経由で到達可能）。
2. RTMPクライアントのAMFシリアライズ問題
外部入力値を固定長でなく可変長でシリアライズした場合にバッファがすぐ溢れる脆弱性です。
パラメータの組み合わせにより、通常テストで現れにくいパスでクラッシュやメモリ破壊が起きます。
3. ICYメタデータのオフバイワンエラー
外部入力値(ch×16)で終端NUL（0）を書き込むと、最大値の時にバッファ1バイト超過書き込みとなる典型的なオフバイワンバグ。
ちょっとした条件設定でしか現れないので多くのテストで看過されていました。
4. RTP（RFC4175）解釈の整数オーバーフロー
画像解像度など巨大なパラメータが与えられると、整数型のオーバーフローで負数になり配列添字が保護をすり抜けヒープオーバーフローにつながります。
5. drawtextのラベル連結でのセパレータ見積もりミス
複数ラベルを連結する際に「, 」などの区切り分が漏れており、全ラベル最大長＋区切り＋終端でバッファサイズを計算し直す必要がありました。
典型的な文字列処理バグですが、外部から最大値が入らないと発現しません。
6. WHIP muxerにおけるストリームインデックス誤利用
内部ストリーム配列が1要素しかないのに多重ループでインデックスを走査し、無効ポインタを解放しようとしてました。
複数ストリーム入の場合のみ現れるため、通常パスのテストでは見逃されます。
7. SCTP書き込み時のヘッダ消費サイズ未チェック
バッファ先頭2バイトをヘッダとして消費する際に「バッファ長>=2」のガードが無く、負値アンダーフローで巨大送信やメモリリーク状態に。
ネットワークプロトコルでは致命的なバグです。
なぜ従来の「fuzzing」「静的解析」では不十分なのか？
fuzzingの限界
記事が強調するもう1つの論点が「fuzzing」（自動入力変換による動的テスト）の弱点です。
“Modern fuzzers excel at exercising decoders that accept single-file inputs. Several of these bugs require: environment-gated paths such as Android MediaCodec, WHIP initialization, or SCTP”
要約すると、
– fuzzingは“ファイル1個を入力するデコーダ”には強いが、「環境特有」「マルチパケット状態」「特定メタデータ注入」など実現が難しい経路はカバーできない。
– また、プロトコルハンドシェイクやマルチプロセス協調、特定のランタイム環境（Android APIなど）は模擬が困難で、多くのデバッグシナリオから漏れがちです。
従来型SAST（静的解析）との違い
“Rule packs catch direct misuse patterns, but frequently miss cross-function resource contracts … These checks require reasoning about intent and units across call chains, not just local anti-patterns.”
とある通り、
– 既存のSASTは“禁止パターン”や“文字列照合”などで限定的なチェックが中心。
– リソース契約（「Aで確保したサイズと、Bでコピーするサイズが論理的に連動しているか」など関数・スコープを越えた整合性）は見逃されがち。
– コードベースが大規模になるほど、「意図された不変条件」の違反を拾うには“推論”“論理的意図の抽出”が必須となります。
AI SAST方式がもたらす新たな潮流―開発の質とセキュリティはここまで進化する
この記事でいちばん重要なのは、「AI型静的解析」のアプローチが、今後の大規模プロジェクトやミッションクリティカルなソフトの設計に必須になりつつあるという示唆です。
従来の開発現場は「テストで落ちないものが正義」的なアプローチに偏り、複数コンポーネントの連携パスや“想定範囲の外”との整合性には切り込めていませんでした。
AI SASTは、
– “契約違反の証明”（単なる「バグがある」ではなく「どのような値で、どんな経路で違反が生じるか」を論理的に提示）
– “補助的なパッチ提案”（大規模プロジェクトでありがちな、影響範囲の自動特定や提案）
– “未知のパスも網羅”（従来テストが触れない経路もカバー）
という形で、今まで発見できなかった根源的な設計バグを素早く洗い出し、「安全」とは何かの定義そのものをエンジニアリングに組み込もうとしています。
結論と示唆：「論理的な安全性」をAIで担保する時代へ
ZeroPathのAI SASTがFFmpegで見つけた7つの論理バグは、どれも「現実に悪用可能」「修正されて初めて安全になった」もので、名だたるOSSにもこうした抜け穴が日夜埋められていることを示しました。
ここから私たちが得るべき教訓は、
– 「テストで落ちなければ良い」「警告がなければOK」といった従来の静的/動的アプローチの安心感を改める必要があること
– 複雑な現代ソフトウェアでは「人間が意図した不変条件」「パーツ間の契約」が正しく守られているかこそが本当の“安全”であること
– その検証を自動化・論理化するAI SASTの導入が今後ますます重要になること
という3点です。
セキュリティ対策は、もはや「後付けの守衛」では十分対応できません。
開発現場の早い段階から、AI SASTのような仕組みを取り入れ、プロジェクト全体として「意図された設計＝現実の挙動」であることを保証していく姿勢が求められています。
OSSの開発者はもちろん、プロダクトやサービスの設計段階に携わる全てのエンジニアにとって、この新しい“論理安全”の概念は避けては通れない現実となるでしょう。
categories:[security]
コメント