Zero-Day Vulnerability Discovered In FFmpeg Lets Attackers Steal Files Remotely
prisoninmate writes: A zero-day vulnerability in the FFmpeg open-source multimedia framework, which is currently used in numerous Linux kernel-based operating systems and software applications, also for the Mac OS X and Windows platforms, has been discovered recently by Russian programmer Maxim Andreev in the current stable builds of the software. It appears to let anyone with the necessary skills hack a computer to read local files on a remote machine and send them over the network using a specially crafted video file. Arch Linux devs already rebuilt their FFmpeg packages without the AppleHTTP and HLS demuxers.
gentoo doesn't have these "features" either.
Ffmpeg is used in some capacity in just about every video application I can think of. VLC, Kodi/XBMC, MythTV, Handbrake, Plex...
Eagles may soar, but weasels don't get sucked into jet engines.
Does ffmpegs fork have the bug as well?
The attack does not even require the user to open that file - for example, KDE Dolphin thumbnail generation is enough. Desktop search indexers (i.e. baloo) could be affected. ffprobe is affected, basically all operations with file that involve ffmpeg reading it are affected
If you have ffmpeg installed, you are likely vulnerable to having any files that you are privileged for transferred across the wore by this bug.
of millions of devleopers and users screaming in terror all at once...
I feel something terrible has happened...
Don't worry, Lennart is busy trying to absorb FFmpeg into systemd. Once there's some Poettering shitcode in FFmpeg, it'll cease to work at all and the vulnerability will have been neutralized.
This is news! A new critical zero-day vulnerability affecting millions of computers.
And here we thought drm free video files were safe.
Whelp another good reason to have a decent firewall.
Minimum threshold fixed. Thanks!
Submitted by prisoninmate. Presumably he's in for crimes against the English language.
He's certainly familiar with really long sentences.
At the bottom of the
To the people who found this wide and deep issue. :)
Any news to who could be using the ability to create and track media files in the wild?
Time to alter the out going software firewall
Domestic spying is now "Benign Information Gathering"
Since I was considerarted a few paranoid when I told You guys that's possible, I prefer keeping my eye on the screen thinking "hmm... there's still something there that I must protect".
AppleHTTP
Didn't we just read about another vulnerability from Apple? What's all this about?
We use ffmpeg to process video files uploaded by customers. We'll be patching our app first thing in the morning. This is a big deal for us.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Isn't this package still available in current versions of TAILS?
They have so much shit (even Java!) packed into their ISOs it's retarded.
If only someone from TAILS would "re-master" their distro to provide slimmer downloads/desktops like Lubuntu or build up from Debian minimal or Tiny Core Linux.
I don't enjoy downloading 1+GB every month nor do I want 1+GB on LiveDVD/USB filled with tons of audio/video editors/players, an office suite, java, and more.
That almost sounds witchcraft level powerful. I'm guessing it depends on more critical factors that weren't mentioned there. Like getting someone to download a copy of that file and play it with some applications that involve ffmpeg. Which sounds a lot less scary than the way the summary phrased it.
The recommended workaround is to disable networking in ffmpeg, but this raises a pretty obvious question. Why would a multimedia library contain any networking code in the first place?
This sounds like a case of faulty functional decomposition in ffmpeg, ie. incorrect program factoring. Even if it performs functions related to handling streamed media, no actual networking should be performed in this library. It shouldn't even be calling upon the services of external networking libraries to perform networking, and it's way out of line that it be establishing any networking connections of its own accord.
Apk builds hosts using 10 reputable security community sources consolidating them all for adblocking and more speed from hardcoded favorites speed with your favorite sites where you spend most of your time online hardcoded at the top of hosts for fastest possible local resolution cached in memory speed up boosts and protection against malware of all kinds with his APK Hosts File Engine 9.0++ SR-4 32/64-bit program http://www.start64.com/index.p...
For less resource consumption and do more than addons. No one builds a better one than apk in his APK Hosts File Engine 9.0++ SR-4 32/64-bit gets known threats from 10 reputable security community sites http://www.start64.com/index.p... and blocks them in the hosts file and speeds you up 2 ways in blocking ads better for way less resources in cpu and ram used in a faster mode of operation in kernelmode than addons do in usermode and stops tracking from sites and dns resolving ip addresses faster than remote dns with hostnames cached in local system memory with your favorite sites where you spend most of your time online at the top of hosts for the fastest possible hostname resolves to ip address and they're reversed dns verified using OpenDNS which is patched against the kaminsky redirect poisoning flaw, and it stops other issues dns has in redirect poisoning by avoiding dns for where you spend most of your time online in your favorite sites hardcoded into hosts at the top of it cached in memory.
The -f option in ffmpeg explicitly chooses the input format, so I would think it would blow up with 'invalid data' if the -f is specified for a video file but there is an HLS header.
-f fmt (input/output)
Force input or output file format. The format is normally auto detected for input files and guessed from the file extension for output files, so this option is not needed in most cases.
For example, if you rename a webm file to an mp4 (reallywebm.mp4), just using ffprobe -i reallywebm.mp4 it returns the input what it really is (Input #0, matroska,webm, from 'reallywebm.mp4'). However, if you add the -f option: ffprobe -f -i reallywebm.mp4 it fails with "reallywebm.mp4: Invalid data found when processing input". So the input file wouldn't be accepted.
Is this another workaround (that doesn't requiring rebuilding without HLS) or am I missing something?
Not again!
instead of contacting developers he:
only then he contacted developers on 2016-01-13...
Lets assume your system is not affected by this. What's the easiest way to detect malicious files and be sure others won't be affected by it?
And safe! And bugless! and . . . . .