Hacker News new | past | comments | ask | show | jobs | submit login
Tell HN: Ffmpeg vulnerability allows attacker to get files from server or PC
69 points by ChALkeR on Jan 13, 2016 | hide | past | favorite | 24 comments
ffmpeg vulnerability allows reading local files and sending them over network using a specially crafted video file. This affects not only file conversion (including thumbnail generation), but also any other operations that involve ffmpeg processing your file — for example, ffprobe is affected.

This is not remote code execution, the vulnerability is limited to reading local files and sending them over network, but that is already bad enough.

For example, a specially crafted «video» file uploaded to your server by an attacker could read your website config/private keys/etc and send that to the attacker once you try to generate a thumbnail for it or just probe it with ffmpeg.

On a PC, you don't even need to open a file to get affected, just downloading it would be enough in some cases — video files are processed with ffmpeg for filemanager thumbnails (i.e. KDE Dolphin), for search indexers, etc.

That vulnerability is public, has code samples to reproduce and build a malicious file, and is not fixed atm.

The recommended quick fix is to rebuild ffmpeg without network support (--disable-network configure flag).

Original post: http://habrahabr.ru/company/mailru/blog/274855/

The original text is in Russian, use https://translate.yandex.com or https://translate.google.com/ to read it.




The key insight is that you can construct an HTTP live streaming playlist that causes the player to pull lines from a series of files, concatenate them together to form a URL then visit that URL, making it possible to exfiltrate data.

It is unclear whether this is ffmpeg-specific, or something the HTTP live streaming protocol actually requires and therefore potentially of wider impact; I can't find any obvious reference to this feature with either a quick Google or a skim of the Apple RFC. Does anyone know?




Heh, this 'feature' was the intended solution of a CTF challenge 3 months ago: https://github.com/ctfs/write-ups-2015/tree/master/9447-ctf-...


Can the malicious video file be an actual mp4 file? We're accepting video and running it through ffmpeg, however we first verify the file is an mp4 using https://golang.org/src/net/http/sniff.go


Possibly? Who knows? Parsers are complex and I doubt ffmpeg relies on file extensions to figure out the format.


It does not, that's covered in the original article.


It does not what? Can you share quotes from the article or the translated article source you read?

Confusion:

Are you saying that ffmpeg doesn't detect file by extension?

or

Are you saying that ffmpeg won't execute the malicious code if it's found appended to a valid video?


But that code that you linked to does not verify that the file is mp4, moreover, mp4Sig call is commented out.


It verifies that the beginning of a file is mp4 format. I'm actually running go 1.6 which does have the mp4 sniffing enabled.


I was under the impression than MP4 could have all of its format specific headers at the end of the file just as well as the beginning according to the spec.


That is correct, however the beginning of the file does have a signature: https://mimesniff.spec.whatwg.org/#signature-for-mp4


Patch on chrome that enabled ffmpeg networking https://codereview.chromium.org/1391383002/patch/1/10001


PC... and also mac? I have ffmpeg installed via homebrew...


It's «PC» as in «server»/«PC», not as in «mac»/«PC».


By the way, mplayer is also affected, even after installing a fixed version of ffmpeg.


Looks like it bundles libavformat internally.


Hm. Why did this end up in [ask]? Perhaps I made a mistake when posting this =).


If there is text in the text box, it goes to "Ask HN" (or "Show HN" when that's in the title).

To post a link, there should just be a title and a link and no comment.



Should I post this again with a link so it ends up in the news or not?


Ship's sailed I think, this is on frontpage, maybe dang will merge them at some point.


Any CVE or answer from upstream about it? Is Firefox as well affected?


This is why you should use containers for running binaries on user-supplied data.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: