PixelSmash：一个恶意视频如何借 FFmpeg MagicYUV 解码器攻击电脑

预计阅读时间：8 分钟

JFrog Security Research 披露了 FFmpeg 媒体框架中的 PixelSmash 漏洞。问题位于 MagicYUV 解码器，可能导致远程代码执行（RCE）或拒绝服务（DoS），并且据披露已存在约十六年。攻击者不需要复杂的网络交互：只要让目标应用处理一个特制媒体文件，就可能触发漏洞。

真正需要关注的不只是 FFmpeg 命令行工具。桌面播放器、视频转码服务、缩略图生成器、内容审核流水线以及其他嵌入 FFmpeg 的应用，都可能把不受信任的视频送进同一套解码逻辑。

风险为什么会扩散到大量应用

FFmpeg 经常作为底层依赖出现。用户可能从未安装或直接运行过 ffmpeg 命令，但某个聊天客户端、素材管理系统或上传服务仍可能静态编译、动态链接或打包 FFmpeg 组件。

PixelSmash 的攻击入口是媒体解码过程。典型场景包括：

用户下载并打开攻击者提供的视频；
Web 服务自动探测上传文件的编码信息；
后台任务生成视频封面、预览图或低码率副本；
安全产品或内容审核系统主动解析附件；
文件管理器、消息应用或媒体库自动生成缩略图。

这意味着“没有主动播放视频”并不一定等于安全。只要应用尝试识别或解码 MagicYUV 内容，攻击面就可能出现。RCE 可能让攻击者在当前进程权限下执行代码；DoS 则可能通过进程崩溃或资源异常消耗中断服务。实际影响仍取决于所用 FFmpeg 版本、构建选项、调用方式以及进程隔离强度。

先确认环境是否暴露 MagicYUV

不要只检查系统包管理器中的 FFmpeg。还应检查容器镜像、桌面应用自带的二进制文件、静态链接程序以及语言包间接携带的本地库。

可以先用下面的脚本检查当前 PATH 中的 FFmpeg 是否公布了 MagicYUV 解码器：

#!/usr/bin/env bash
set -euo pipefail

if ! command -v ffmpeg >/dev/null 2>&1; then
  echo "ffmpeg is not available in PATH"
  exit 2
fi

echo "FFmpeg binary: $(command -v ffmpeg)"
ffmpeg -version | sed -n '1,3p'

if ffmpeg -hide_banner -decoders 2>/dev/null | grep -i 'magicyuv'; then
  echo "RESULT: MagicYUV decoder is present; verify the installed version and patch status."
  exit 1
else
  echo "RESULT: MagicYUV decoder was not listed by this binary."
fi

将其保存为 check-magicyuv.sh 后运行：

chmod +x check-magicyuv.sh
./check-magicyuv.sh

这个检查只能说明被调用的二进制是否列出了相关解码器，不能证明整台机器或整个产品没有风险。应用可能携带另一份 FFmpeg，也可能通过 libavcodec 直接调用解码能力。软件资产清单应进一步覆盖：

find /opt /usr/local /srv -type f \( -name 'ffmpeg' -o -name 'libavcodec.so*' \) 2>/dev/null

发现文件后，应分别查询其来源、版本和构建配置，并与供应商发布的修复信息核对。不要仅根据系统中的主版本号推断某个内嵌副本已经修复。

修补之前，缩小解码器和进程权限

优先措施是升级到包含修复的 FFmpeg 版本，或者安装操作系统及应用供应商提供的安全更新。如果业务完全不需要 MagicYUV，可以在自建 FFmpeg 时禁用该解码器。下面是一个可改造的构建示例；实际依赖和安装路径应按项目环境调整：

./configure \
  --prefix=/opt/ffmpeg-hardened \
  --disable-decoder=magicyuv

make -j"$(getconf _NPROCESSORS_ONLN)"
make install

/opt/ffmpeg-hardened/bin/ffmpeg -hide_banner -decoders 2>/dev/null \
  | grep -i magicyuv \
  && { echo "MagicYUV is still enabled"; exit 1; } \
  || echo "MagicYUV decoder is not exposed"

禁用解码器会牺牲相应格式的兼容性，但对于只接受 H.264、HEVC、VP9 或 AV1 等明确格式的服务，这通常比保留不必要的解码面更合理。需要注意，命令行参数或格式白名单不能替代安全补丁；在底层解析已经开始后，应用层扩展名检查也可能太晚。

面向公网的视频处理服务还应把 FFmpeg 放进低权限、可丢弃的执行环境。可以这样实践：以非 root 用户运行任务，使用只读根文件系统，限制 CPU、内存和执行时间，禁止访问宿主机凭据，并隔离每个上传任务。即使解码器再次出现内存安全问题，这些边界也能降低代码执行后的影响范围。

排查与上线清单

处理 PixelSmash 时，可以按以下顺序推进：

枚举服务器、终端、容器和桌面产品中所有 FFmpeg 或 libavcodec 副本。
检查每个副本是否包含 MagicYUV 解码器，而不是只检查系统默认命令。
根据 FFmpeg、操作系统和应用供应商公告确认修复状态并应用补丁。
不需要 MagicYUV 的构建直接禁用该解码器，并加入持续集成检查。
将媒体解析任务放入低权限、无凭据、资源受限的隔离环境。
对崩溃、异常退出、超时和同一文件的重复处理失败建立告警。
在补丁部署后重新扫描生产镜像，防止旧二进制从基础镜像或应用包中回流。

PixelSmash 再次说明，媒体文件不是被动数据。解码器会解析复杂、由攻击者控制的二进制结构，其风险模型更接近文档解析器和网络协议栈。修补当前漏洞是必要动作，长期措施则是减少可用解码器、隔离解析进程，并让嵌入式 FFmpeg 进入正式的软件资产和补丁管理流程。

PixelSmash：一个恶意视频如何借 FFmpeg MagicYUV 解码器攻击电脑

风险为什么会扩散到大量应用

先确认环境是否暴露 MagicYUV

修补之前，缩小解码器和进程权限

排查与上线清单

相关推荐

建议反馈