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".
You seem to be captured by the “all or nothing” security fallacy, when security must be viewed through the lens of (probability) x (impact)
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
Because it's in the PDF spec, and you can't randomly disable parts of that.
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 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.
It's worth pointing out that many, many, many things use the libav* library family.
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.
It's used way, way more than you think.
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.
It’s used for pretty much any platform you can upload video to. Some places far more competently than others.
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.
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).
If Signal relies on ffmpeg to play videos instead of an externall app, i would say it is broken by design.
> VLC is pretty popular on windows, but ffmpeg?
> Is there any commonly used windows app that relies on it?
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.
Or in, you know, external libraries. Maybe ffmeg shall be run with sanitized input (and not from a "web page" ) ? Just saying
D.V.L. sanm LucasArts SANM/SMUSH video