Security risks of using ffmpeg as part of web service

Question

I'm working on a web service that uses ffmpeg on the backend for processing user uploaded media files. I'm giving the users some options to customize how their videos are processed, which is essentially parameterize the ffmpeg command.

I'm planning to run ffmpeg in a Docker environment, possibly with a new container per execution. Regardless, this environment could be used to execute arbitrary code and might have have access to some of my secrets.

Beyond command-line injection, are there any other security concerns to consider here?

I am running ffmpeg inside a docker container with networking disabled and passing the input and output files via a shared directory.

The command below does the following:

• Puts the input file into a shared directory with the container
• Runs ffmpeg inside the container with whatever options are passed
• Puts the output file into the host shared directory, where the host will then copy it to it's final storage location

Command:

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

A few notes:

• TEMP_DIR_ON_HOST is a single use directory for one conversion
• FFMPEG_OPTIONS are scrubbed, but could potentially contain injection
• I'm not locked into the jrottenberg/ffmpeg image, I might make a copy or at least lock down to a particular version.

I think that disabling networking and limiting outside file access greatly reduces the risk even if malicious commands are injected somehow.

Are there any major risks beyond wasted resources?

Answer 1

Yes there are security risks, especially if you allow arbitrary formats. FFmpeg supports a huge variety of formats, both popular and obscure, for video, audio, and images. Any vulnerability in decoders for any of the numerous formats could be exploited to gain arbitrary code execution. This becomes even more likely given the fact that FFmpeg is written in C, which is not memory safe, and is optimized for speed instead of security. You must assume any untrusted input passed to FFmpeg can be used to gain full arbitrary code execution in the context of the running process and build your threat model around that.

There are a few things you can do to mitigate potential risks in addition to hardening Docker:

• Seccomp sandboxing - Enable seccomp in Docker to limit the syscalls that can be made. A syscall, or system call, is the interface used by userspace to communicate with the kernel. Certain syscalls are complex and can be insecure, opening up bugs in the kernel to exploitation.

• Formats/codecs - Disable unused decoders to reduce the attack surface area of the decoder. Many formats, or formats with obscure features, have low-quality decoders that are not regularly checked for bugs. While the Opus decoder is likely of acceptable quality, what about G.726?

• Resource limits - Restrict resources that any given FFmpeg process can use. Resources can not only be used to DoS the system, but can be necessary to exploit other vulnerabilities to elevate privileges, for example certain kinds of integer overflows that require large memory allocations.

• Mandatory Access Controls - Use a MAC like AppArmor or SELinux to restrict accesses and protect sensitive objects, even in the case of a Docker breakout. You can also use a MAC to limit network connections, since there is no reason FFmpeg should upload or download data.

• Compiler hardening - Use hardening when building FFmpeg, or download a hardened version. Compiler hardening like PIE, SSP, and FORTIFY_SOURCE can make vulnerabilities harder to exploit. PIE is especially important, as it allows the operating system to make full use of ASLR.