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.<p>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.<p>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.<p>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.<p>That vulnerability is public, has code samples to reproduce and build a malicious file, and is not fixed atm.<p>The recommended quick fix is to rebuild ffmpeg without network support (--disable-network configure flag).<p>Original post: http://habrahabr.ru/company/mailru/blog/274855/<p>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.<p>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: <a href="https://github.com/ctfs/write-ups-2015/tree/master/9447-ctf-2015/web/super-turbo-atomic-gif-converter" rel="nofollow">https://github.com/ctfs/write-ups-2015/tree/master/9447-ctf-...</a>
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 <a href="https://golang.org/src/net/http/sniff.go" rel="nofollow">https://golang.org/src/net/http/sniff.go</a>
Patch on chrome that enabled ffmpeg networking <a href="https://codereview.chromium.org/1391383002/patch/1/10001" rel="nofollow">https://codereview.chromium.org/1391383002/patch/1/10001</a>