FFmpeg 中的二十一项零日漏洞

对 FFmpeg 漏洞严重性的看法

• 许多人认为这些 RTSP/RTP 问题很严重，因为它们可能影响摄取管线、监控/CCTV 系统，以及接受攻击者控制 URL 的转码服务。
• 也有人指出，真实利用很可能需要与 ASLR 泄漏或其他漏洞进行链式利用，不过媒体栈众所周知很容易泄露地址。
• 还有人认为这 21 个问题里很多都很小众，需要糟糕的部署实践，或者只是更大利用链中的一步。

FFmpeg 的安全记录与态度

• 评论者表示，FFmpeg 长期以来一直有通过 fuzzing 发现的、源源不断的内存破坏漏洞，而且在不受信任输入上不加沙箱地运行并不安全。
• FFmpeg 被描述为对安全报告持敌意或轻蔑态度；有人认为这可以理解为倦怠，也有人认为这是不负责任。
• 对于一些冷门编解码器漏洞有多“大事”存在分歧；一些开发者视角会淡化它们，而另一些则强调攻击者可以选择任何受支持的编解码器。

沙箱、部署与现实世界风险

• 据称，浏览器会把类似 FFmpeg 的组件运行在独立的沙箱进程中，并配合分配器加固；不过，链式沙箱逃逸仍然是威胁。
• 建议的缓解措施包括：容器、firejail/bubblewrap、gVisor、虚拟机，或类似 Qubes 的按应用虚拟机，不过硬件加速和 GPU 会让沙箱化变得复杂。
• 有些人接受电视/嵌入式设备实际上等同于未沙箱化，并建议在网络层面隔离它们。

替代方案与重写（Rust、GStreamer 等）

• GStreamer 被讨论为一种可插拔的媒体图系统；它可以封装 FFmpeg，但也有自己的编解码器和元素。
• 有几个人呼吁“用 Rust 重写”，但也有人认为：
  • FFmpeg 的热点路径和汇编代码仍然需要 unsafe，而且不会自动修复逻辑漏洞。
  • 直接移植可能会在新语言里重现同样的漏洞。

“零日”术语之争

• 多条评论指出文章对“零日”一词的用法不当；从历史上看，它指的是在披露之前或披露时就已被利用，而不只是“严重漏洞”。
• 讨论还区分了漏洞与利用程序，以及这个术语的含义如何发生了漂移。

安全研究、LLM 与激励机制

• 有人强烈批评追逐名气的研究者，以及淹没维护者的低质量、由 LLM 生成的报告。
• 也有人反驳说，漏洞本身的存在与研究者的行为无关。
• 还有人认为工具不应只提交报告，而应提交高质量 PR；据称在这样做时成功率很高。
• 少数人担心先进的基于 LLM 的工具可能会悄悄发现并囤积强大的利用手段。