Featured Blog – Independent Security Evaluators’ Perspective on FFmpeg and Security

April 24, 2013 · Posted in Cyber Blog, Latest News 

Introduction

FFmpeg is a complex software project designed to process virtually every video format in existence. Video formats can be extremely complex as well, and writing a new encoder or decoder is an expensive and error-prone task. Application vendors instead use FFmpeg, a freely available library, to process video files.

Like most large, complex software libraries, security vulnerabilities in FFmpeg have been discovered and repaired in new releases. It should be noted that FFmpeg’s past vulnerabilities do not indicate a poor quality product, and the fact that a given system relies on FFmpeg should not be considered a security vulnerability.

Background

FFmpeg is written in C++, which, compared to other programming languages, compromises some amount of safety in favor of high performance and speed. In particular, the C++ language does not inherently protect against buffer overflow attacks. Successfully exploiting an unchecked buffer vulnerability allows an attacker to rewrite the executable code of a program at runtime with different code of the attacker’s choice, allowing an attacker to take control over the computer.

An attacker can take advantage of unchecked buffer vulnerabilities by carefully crafting a malicious video file that may not even be playable or contain any frames or audio. When FFmpeg processes the malicious file, the vulnerability is exploited and the attacker’s code embedded within the video file is executed. Figure 1 shows how an attacker could take advantage of a publically accessible, vulnerable system to gain access to the backend network to which the vulnerable system is connected. If the backend network is not carefully segmented, this allows the attacker to bypass the firewall.

Figure 1. An attacker crafts a malicious video file and transmits it to a vulnerable system. As this is legitimate access to the system, it is not blocked by the firewall or other perimeter defenses. A successful buffer overflow exploit could provide the attacker with full control over the vulnerable system, providing a network pivot point to access and attack other systems on the backend network, even if they are not vulnerable to the particular buffer overflow attack and would normally be protected by the firewall.

The FFmpeg 0.11 version, released in 2012, fixed 28 vulnerabilities that were notable enough to receive a CVE (Common Vulnerabilities and Exposures) number. The utility and versatility of FFmpeg produce a “perfect storm” of potential security issues. FFmpeg supports 197 different file formats and 166 different video codecs. Each format requires its own module of code within the library to process it. Every file format provides a different potential attack surface for FFmpeg, and many of the formats are little-used or obsolete, and therefore not a source of many bug reports.

Attacking FFmpeg via an unchecked buffer vulnerability requires detailed knowledge about the target system. Buffer overflow exploits targeted at one platform will not likely succeed on another. Necessary information includes the type and version of the operating system, exact version of FFmpeg, and potentially more details, such as the compiler flags used when building FFmpeg. However, an attacker can fingerprint vulnerable systems in many ways, and in particular, ISE has found that the FFmpeg library embeds its version number within files when encoding them. If an attacker has access to a video file generated by a vulnerable system, then the attacker could most likely obtain enough information about the system to craft an exploit.

Consequences

A reason for concern, is that FFmpeg may be used on systems processing sensitive assets, such as unreleased video footage. In addition to an attacker obtaining these assets, an attacker could use a vulnerable system as a pivot point to gain further access to customer or vendor networks, or could use the compromised system for unrelated illegal purposes, such as hosting pirated content or launching a subsequent attack.

Of note is the fact that once a system is successfully compromised, not only are all assets on the system at the time potentially compromised, but as long as the attack remains undetected, any additional assets processed by the system in the future may also be compromised.

Mitigations

Users of FFmpeg should take several steps to minimize risk. The simplest and most effective mitigation is to always update to the latest release of FFmpeg, especially when security vulnerabilities are found and patched. Keep in mind that developers using FFmpeg cannot reasonably be expected to update instantaneously when a new release is issued, and there is the potential of zero-day attacks (those discovered and used by attackers but not yet known to the software provider). As part of a general defense-in-depth strategy, systems utilizing FFmpeg can take additional precautions:

  • Applications that process external inputs (such as uploaded files) should always run on a low-privileged user account. They should never run as root (on Unix) or an administrator (on Windows).
  • Compiler and operating system features that help to prevent some, but not all, buffer overflow exploits should remain enabled.
  • Sensitive assets (e.g. video content) should never be stored on the same system that processes external inputs.
  • Modular libraries, such as FFmpeg, can often exclude unneeded features or file formats when compiled. If a vulnerability is specific to the module for one file format, and that format is not included, then the resulting copy of FFmpeg becomes immune to that vulnerability.

Conclusion

This memo should not be taken as a security advisory for using FFmpeg, or an insistence against using FFmpeg. As with any software, there are security concerns, awareness, and particular configuration and hardening guidance that should be understood when adopting the technology. A good summary of FFmpeg and its risk of security issues is given on the About FFmpeg page of the FFmpeg project web site1.

Comments

Comments are closed.