使用 ffmpeg 作为 Web 服务的一部分的安全风险

信息安全 风险管理 沙盒 码头工人 漏洞评估
2021-08-12 20:28:42

我正在开发一个ffmpeg在后端用于处理用户上传的媒体文件的 Web 服务。我为用户提供了一些选项来自定义他们的视频处理方式，这本质上是参数化ffmpeg命令。

我计划ffmpeg在 Docker 环境中运行，每次执行可能使用一个新容器。无论如何，这个环境可以用来执行任意代码，并且可以访问我的一些秘密。

除了命令行注入之外，这里还有其他需要考虑的安全问题吗？

我在ffmpeg禁用网络的 docker 容器中运行，并通过共享目录传递输入和输出文件。

下面的命令执行以下操作：

  • 将输入文件放入与容器共享的目录中
  • ffmpeg使用传递的任何选项在容器内运行
  • 将输出文件放入主机共享目录，然后主机将其复制到其最终存储位置

命令：

docker run -v <TEMP_DIR_ON_HOST>:/temp/ --network none \
    jrottenberg/ffmpeg -stats \
    -i /temp/<INPUT_FILE> \
    <FFMPEG_OPTIONS> \
    /temp/<OUTPUT_FILE>

几点注意事项：

  • TEMP_DIR_ON_HOST是一次转换的一次性使用目录
  • FFMPEG_OPTIONS 被擦洗，但可能含有注入
  • 我没有被锁定在jrottenberg/ffmpeg图像中，我可能会复制或至少锁定到特定版本。

我认为即使以某种方式注入恶意命令，禁用网络和限制外部文件访问也会大大降低风险。

除了资源浪费之外，是否还有其他重大风险？

1个回答

是的，存在安全风险，尤其是在您允许任意格式的情况下。FFmpeg 支持多种格式，包括流行的和晦涩的视频、音频和图像。多种格式的解码器中的任何漏洞都可以被利用来获得任意代码执行。考虑到 FFmpeg 是用 C 语言编写的，这种情况更有可能发生，这不是内存安全的，并且针对速度而不是安全性进行了优化。您必须假设传递给 FFmpeg 的任何不受信任的输入都可用于在运行进程的上下文中获得完全的任意代码执行，并围绕它构建您的威胁模型。

除了强化 Docker之外，您还可以采取一些措施来降低潜在风险：

  • Seccomp 沙盒- 在 Docker 中启用 seccomp 以限制可以进行的系统调用。系统调用或系统调用是用户空间用来与内核通信的接口。某些系统调用很复杂并且可能不安全，从而导致内核中的漏洞被利用。

  • 格式/编解码器- 禁用未使用的解码器以减少解码器的攻击面。许多格式或具有晦涩功能的格式具有不定期检查错误的低质量解码器。虽然Opus解码器的质量可能可以接受，但G.726呢？

  • 资源限制- 限制任何给定 FFmpeg 进程可以使用的资源。资源不仅可以用于 DoS 系统，还可以用于利用其他漏洞来提升权限，例如需要大量内存分配的某些类型的整数溢出。

  • 强制访问控制——使用像 AppArmor 或 SELinux 这样的 MAC 来限制访问并保护敏感对象，即使在 Docker 突围的情况下也是如此。您还可以使用 MAC 来限制网络连接，因为 FFmpeg 没有理由上传或下载数据。

  • 编译器强化- 在构建 FFmpeg 时使用强化，或下载强化版本。像 PIE、SSP 和 FORTIFY_SOURCE 这样的编译器强化可以使漏洞更难被利用。PIE 尤其重要，因为它允许操作系统充分利用 ASLR。

其它你可能感兴趣的问题
上一篇链接重定向到 http 而不是 https：它有多重要？ 下一篇这种无密码身份验证流程是否安全？