上週，@FFmpeg 帳號開始嘲諷安全研究人員。這種做法很愚蠢，因為它忽略了他們攻擊面與我們攻擊面之間的不對稱性。 為了練習，我找到了他編寫的軟體中的一個基於堆疊的緩衝區溢位漏洞。我花了大約 20 分鐘才找到。貼文🧵(1/5)
首先，我注意到FFMpeg的帳號並非由FFMpeg的活躍開發者控制，而是由幾個人共同管理，其中一個名叫Keiran。這很奇怪，但並不重要。 keirank GitHub 用戶提交的更改很少，沒有提交任何關於 FFMPEG 的更改，但提交了 Upipe，這是他公司開發的視訊處理軟體。 那麼讓我們來看看他最近的提交「驗證 num_delta_pocs 以避免堆疊溢出」。 （2/5）
@FFmpeg 確實，@FFmpeg 編寫了一個驗證程序，但是儘管處理的是不同維度的二維數組，它卻只檢查一個索引。 這肯定不對。由於我沒有時間驗證，所以我指示一位LLM（法學碩士）「查找程式碼中的關鍵錯誤」。 GLM 4.6 發現了很多 (3/5)
每次計算預測幀時，都會增加參考圖片數組，但這在驗證中並未考慮。 溢位（讀取過多）。 因此，我們有辦法從堆疊中超讀最多 64 個位元組（64 是參考幀的最大數量）。 但是我們能直接寫入堆疊嗎？我讓LLM寫一個h265幀模糊測試器，它非常複雜，但它一次性就完成了（4/5）。
@FFmpeg 現在出現了基於堆疊的讀寫緩衝區溢位漏洞。遊戲結束。 模糊測試器和完整說明可以在我的 GitHub 上找到： https://t.co/7m0i6Dmvud
