I wonder if this vulnerable codec is enabled by default when building FFmpeg? Because if so, then it doesn't matter that it's a "1990s game codec" because any application using FFmpeg to accept arbitrary video files is vulnerable to memory corruption, which should probably be taken more seriously.
The somewhat depressing reality is that if you're running ffmpeg on user-supplied multimedia without putting it in a bulletproof sandbox, you're just bound to have a bad time.
Video decoding is one of these things that no one seems to know how to do safely in C or C++, not in the long haul. And that's probably fine, because we have lightweight sandboxing tech that makes this largely moot - but there's an extra step you need to take. Maybe it's on the ffmpeg project that they don't steer people in that direction.
Trying to fix these bugs piecemeal is somewhat pointless - or at least, we've been trying for several decades, throwing a ton of manpower and compute at it, and we're still nowhere near a point where you could say "this is safe".
Does this mean we have to run vlc in a sandbox while watching a downloaded film?
In production? With a user-supplied film?
You seem to be captured by the “all or nothing” security fallacy, when security must be viewed through the lens of (probability) x (impact)
It isn't even like this is without precedent, the FORCEDENTRY NSO kit used the shitty old JBIG2 parser that Apple was shipping as its entry point despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.
> despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.
Then why it has been enabled ? Asking for a friend. /s
Unless Apple, ffmpeg has a reason to enable old codecs. If you only need a subset: configure; make; make install
> Then why it has been enabled ? Asking for a friend. /s
Because it's in the PDF spec, and you can't randomly disable parts of that.
I checked with Ubuntu's ffmpeg and it is enabled by default. There are a huge list of codecs enabled by default (maybe all of them?). Given the security track record of codecs implemented in C, this means it's basically guaranteed that there are dozens of security vulnerabilities in ffmpeg.
I think the same is probably true for VLC to a lesser extent, which is pretty wild considering I've never heard of it being used as an attack vector, e.g. via torrents.
I think that the x264 and hevc codecs are much more battle tested and a 0day for them would be worth enough that nobody would bother using it on random torrenters.
But you don't need to use a popular codec, because all codecs are enabled by default.
Yeah but most public trackers will give lots of side eye to torrents that contain an mkv that isn’t in one of those two formats.
Really? You think trackers download files and analyse their contents before listing them? I don't.
TPB? No. But 1337 and rutracker definitely do basic quality control. Nothing like a private tracker but they take down things like .mkv.lnk and similar.
> Given the security track record of codecs implemented in C, this means it's basically guaranteed that there are dozens of security vulnerabilities in ffmpeg.
Or in, you know, external libraries. Maybe ffmeg shall be run with sanitized input (and not from a "web page" ) ? Just saying
VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux
ffmpeg is deployed everywhere, and old versions of ffmpeg are baked into a lot of devices.
If you have a device that does image, audio or video, libav and/or ffmpeg is likely somewhere in the stack. Your TV, camera, console or streaming device might use the software.
If you're using SaaS that does image, audio or video, they are likely using ffmpeg related software somewhere in their stack.
Same thing with apps, Android and iOS apps might use the libraries, as well as desktop apps.
VLC and ffmpeg share the same underlying library family (libav*) where this vulnerability lives.
> I doubt it'd be worth one's time to write exploits for desktop Linux
How many developers, network administrators, etc. run desktop Linux? Gaining access to those can be very, very valuable.
FFmpeg based players have been popular for 20 years now. Has there been a single documented actual use of their libraries as the exploitation vector anytime in the last two decades?
Does this count?
https://signal.org/blog/cellebrite-vulnerabilities/
> Given the number of opportunities present, we found that it’s possible to execute arbitrary code on a Cellebrite machine simply by including a specially formatted but otherwise innocuous file in any app on a device that is subsequently plugged into Cellebrite and scanned. There are virtually no limits on the code that can be executed.
But it was a product using a 9 year old ffmpeg build (at the time).
I'd still consider that an academic exercise rather than an exploit that was deployed in the real world (aka against a machine the attacker did not control)
Yeah, that’s just how life is. We used to run with Heartbleed and Spectre turned off.
> Does this count?
If Signal relies on ffmpeg to play videos instead of an externall app, i would say it is broken by design.
I'm certain it's happened but since I don't have one off the top of my head I'll instead point out a related issue: https://en.wikipedia.org/wiki/Stagefright_(bug)
It's worth pointing out that many, many, many things use the libav* library family.
Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still.
If the exploit chain involves the user downloading and opening a file, something like >99% of the time the next step already involves executable code (or Office macros), which makes any ffmpeg vuln completely useless.
In a past life as a managed hosting provider ffmpeg exploits were used to gain access to systems.
It’s used for pretty much any platform you can upload video to. Some places far more competently than others.
See, I’d be interested in any actual evidence/writeups of that in the wild.
In fairness, i dont think the majority of actual exploits used in the wild get writeups.
Budget web host using outdated software getting hacked because they havent updated in 2 years isn't exactly all that interesting of a blog post even if the victim knows enough to figure out what happened.
Chrome uses ffmpeg's underlying libraries.
It's used way, way more than you think.
Yes, I’m quite familiar with that. Chrome is why I added the “generally” qualifier.
And to the best of my knowledge, there has not been any in-the-wild exploit against Chrome through the handful of ffmpeg codecs they enable. Not even pwn2own type competitions either, as I recall.
I guess I'm confused - are you trying to imply the lack of a thorough, publicly reported successful exploit (or us just not casually giving you one that you care about) means that we're all released from the responsibility of taking potential exploits seriously?
Depends if any important websites are re-compressing user-uploaded videos. If there's a website converting user-uploaded gifs to mp4 to save on bandwidth or something, I wouldn't be surprised if they used ffmpeg to do it.
Yes, lots. To name an example, yt-dip uses it on all platforms, including Windows, which means that any video downloader front-end that uses it also uses FFmpeg.
...I mean "yt-dlp", of course. Phone autocorrected >_<
No, all the ancient video game codecs and other such things that are there for historical preservation purposes but are rarely actually used are disabled by default and you have to really go out of your way to enable them. This was originally for binary size/build time reasons.
Are you sure? I ran `ffmpeg -codecs` on Ubuntu and it lists