先週、@FFmpeg のアカウントがセキュリティ研究者を挑発し始めました。彼らの攻撃対象領域と私たちの攻撃対象領域の非対称性を無視した、愚かな行為です。 練習として、彼が書いたソフトウェアにスタックベースのバッファオーバーフローがあるのを見つけました。見つけるのに20分ほどかかりました。スレッド🧵(1/5)
まず、FFMpegのアカウントはFFMpegの現役開発者ではなく、どうやら複数の人物によって管理されているようです。そのうちの一人はKeiranという人物です。奇妙ですが、大したことではありません。 keirank の github ユーザーはコミット数が非常に少なく、FFMPEG には全くコミットしていませんが、彼の会社のビデオ処理ソフトウェアである Upipe はコミットしています。 それでは、彼の最新のコミット「スタックスマッシュを回避するために num_delta_pocs を検証する」を確認してみましょう。(2/5)
@FFmpeg 確かに @FFmpeg は検証を記述しましたが、さまざまな次元の 2 次元配列を扱っているにもかかわらず、 1 つのインデックスしかチェックしません。 これは正しくないはずです。検証する時間がなかったので、法務・法務・法務の専門家に「コード上の重大なバグを見つける」ように指示しました。 GLM 4.6では多くの（3/5）が見つかりました
予測フレームが計算されるたびに参照 pic 配列が増加しますが、これは検証では考慮されません。 オーバーフロー（オーバーリード）。 したがって、スタックから最大 64 バイト (64 は参照フレームの最大数) をオーバーリードする方法があります。 でも、スタックに書き込むことはできるのでしょうか？ LLMにH265フレーマーファジングツールを書いてもらいました。非常に複雑なのですが、ワンショットで処理できます。(4/5)
@FFmpeg これで、スタックベースの読み取り/書き込みバッファオーバーフローが発生しました。ゲームオーバーです。 ファザーと完全な説明は私の github にあります: https://t.co/7m0i6Dmvud
