Comment by zerobees
2 days ago
Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago:
https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
So, while it's a demo of the capabilities of LLMs, this should not be at all surprising. Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. I know that people do, and these people are taking unreasonable risks.
FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.
On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through.
Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.
If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.
On the third hand, pestering and shaming open-source maintainers because they don't accept your PR is how you get the XZ backdoor situation.
There is a different dynamic between this and that.
Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no?
I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.
If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance.
https://news.ycombinator.com/item?id=43140614
2 replies →
No. They tried that with coreutils and look what happened. More CVEs.
99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
12 replies →
Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up.
They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used.
I was left wondering whether they were oblivious to the fact that an attacker who can supply a video file to you is free to use whatever video codec they want? It wouldn't matter if the developers thought the codec was never used at all; if it is still available then an attacker can use it.
Or was I just missing something? Is there a good reason why vulnerabilities in this codec are not a big deal after all?
Is it really available in practice ? Eg. do major distros even compile ffmpeg with these obscure codecs or you need to recompile it yourself to get it ?
Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.
The user is not free to use whatever codec they want. Many niche codecs can't be put into the usual containers, so if you only accept QuickTime/MP4 and AVI, sometimes even just by limiting the file extension, those codecs can't be used.
If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up. It would be nice if you could do that, but that's not a guarantee ffmpeg has ever provided, nor would it make sense for them to spend their limited resources on it.
> If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up.
Isn't that what fuzzing and input validation is about? Most bugs presented in article suggest failures in the latter.
Big pipeline fat data users of ffmpeg can and do build their own executables that only include the top N codecs, that eliminates minor bug in obscure never used format problems pretty thoroughly.
I’m this video you will also learn that much of it is coded in assembly! The developers are prioritizing performance to the extreme, which has its benefits, but I would expect assembly to open up the code to a whole world of vulnerabilities.
Of course. Everybody knows to rather use the obvious alternative to ffmpeg!
> the obvious alternative to ffmpeg
IIRC that is currently sandboxed ffmpeg.
Until the people going on about making an equivalent in pure rust being automatically much safer, stop talking about it and actually get on with making it, of course!
FFmpeg is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain.
It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.
For the implemented formats, wuffs is safer and also often faster: https://github.com/google/wuffs
while sandboxing ffmpeg directly isn't difficult, unfortunately with something like MPV/VLC that uses ffmpeg it's more challenging. until recently (virtio gpu native context) it wasn't even possible to sandbox a video player without losing all hardware acceleration. at least not from the outside, they could always try to sequester ffmpeg and seccomp it to hell like chromium.
Sandboxing not only OS access but also hardware access feels almost impossible to be honest. At least not via user-friendly exec based stuff like bwrap.
Personally, I still try to contain them a bit: https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles
They're also extremely hostile to security researchers who report these issues.
I wouldn't call "nice find, care to help us fix that?" extremely hostile. It can be frustrating for open source projects that far more people want a pat on the back for the identification of a problem (be it security, performance, documentation, or anything else) than there are people who have the time and inclination to help resolve the issue (or ability and inclination to fund the project so it can more easily find help if needed). The use of LLM based tools apparently making that pat on the back easier to attain is going to exacerbate that problem for a while at least.
I don’t deal with ffmpeg or C/asm, but there are certainly some 4gl applications that a random patch may cause more problems than it solves. I imagine many researchers would be in that box.
https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw...
Security is the punch line for ffmpeg.
I'm glad to see their sense of humour :-)
https://nitter.net/ffmpeg/status/2039115531744334180
3 replies →
Oh my god! They are so funny and memeable! gets RCE'd
In their defense, the "rewrite it in rust" crowd can be really grating.
Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.
1 reply →
The guy running the twitter account is incompetent but the actual devs are a lot saner I think.
I agree it reflects poorly on them though
> … hostile to security researchers who report these issues.
Do you have an example?
I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.
1 reply →
I have numerous examples of security researchers being hostile and impossible to work with (but cannot share them unfortunately).
One dude running an X account is not indicative of a community to be honest.
That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.
I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.
2 replies →
If there was a nearly inexhaustible supply of Indian security researchers emailing you a nearly inexhaustible supply of LLM slop daily, there is a point where you or I would stop caring too.
ffmpeg is Free Software. You are also free not to use it.
Oddly enough, despite all these endless grievances, no one has come up with a better or more capable tool, certainly not one that is freely available.
Evidently no one cares either, because most implementations of ffmpeg I've seen typically run it as root "because we have to". Don't worry we use Docker bro.
You should rethink this kind of casual racism.
> nearly inexhaustible supply of LLM slop daily,
Actual well written vulnerability reports are not the same as slop.
AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.
Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.
> AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.
Ok but who is going to sift through it all to triage the good bits when you're working on something for free?
> Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation
Who gives a shit about reputation when you're the only game in town?
There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.
15 replies →
Even before the advent of AI the quality of most reports was depressingly low. Most of your reports will quite simply come from folks in lower-wage countries that broadly don't speak English well and that use a shotgun approach to bug bounties. That means you are receiving a lot of them, they will be hard to read (assuming the information you need is in there at all) and if they get one success out of fifty then for them it is a really good return.
The advent of LLMs has made this a hundred times worse. Both because it makes it easier for most people to create reports that sound good (and so are more effort to dissect) and because people who didn't have to work hard to get any amount of competence are usually more entitled and more rude (the stakes are even lower for them).
It is economically no longer a good idea to run a bug bounty program at all. I honestly question whether or not even having a direct input for such things makes any sense anymore. The volume is becoming so great you need a classical spam filter to plow through it. But that won't work, because they all sound reasonable.
Funny, John Carmack was just admiring the creator of ffmpeg the other day for being a better programmer. https://x.com/id_aa_carmack/status/2064095424420487226?s=46
The majority of code in ffmpeg today isn't written by Fabrice, but also there's multiple axes that people view programming ability on. Some people can write software that will do things you couldn't imagine given the constraints. Some people can write software that is resilient against all malformed input. Sometimes these people are the same people, but frequently they're not.
One thing has nothing to do with the other.
Security vulnerabilities are less about programming ability and more about rigor.
[flagged]
Can't help laughing at a random ad hominem against John Carmack of all people, and about his opinion on a guy who is already widely regarded as an especially talented programmer.
1 reply →
I don't think that's fair. There's a lot of talent and grit behind ffmpeg. But for better or worse, getting the code to do what it's supposed to do requires a different mindset than getting it to not do anything else (i.e., to handle malicious inputs correctly).
The developers of ffmpeg are very good at the first thing and not very good at the second. But few people on this planet, if instructed to write a complex video format parser in C or assembly, can produce something that's secure on the first try. The main failing of the ffmpeg team is that they should have spent more time on architectural hardening and mitigations. Most other large projects of this type do.
3 replies →
So who is someone who's opinion is worth anything to you?
Except yourself, presumably, to me it almost seems nobody is perfect.
2 replies →
The difficulty in exploiting ffmpeg is getting anyone to use it on your input. Sure, you might pwn a few people, but is it worth the effort?
I use it in WASM on the client and call it a day. It works for our use case, but obviously not most.
Is GStreamer a more secure alternative or does it just get a bit less attention than ffmpeg?
Any multimedia project trying to support a large number of formats, whose usage in the wild differs by orders of magnitude, is going to have code of varying quality (although quality is not strictly correlated with usage: age and complexity are also big factors, among others). GStreamer puts plugins into different categories (-good, -bad, etc.) based on things like the maturity of the code, which helps you judge what risks you are taking. With FFmpeg it is harder to know which formats are more likely to have issues. Of course GStreamer can use FFmpeg, in which case you will also have all of FFmpeg's problems.
In both cases you are best off restricting things to what you actually use.
Gstreamer is a multimedia framework where the user creates media DAGs by placing video/audio/multimedia elements such as demuxers, decoders etc in a pipeline. The framework then takes care of running the media pipeline and handles the data buffering etc.
Within the framework there are multitudes of plugin packages that contain said elements and many of them are built on top of ffmpeg.
From what I understand gstreamer is more about building complex pipelines and plugins, ffmpeg is better at playing some obscure 20 year old video format extremely efficiently so you can watch it compiled for a potato.
Different cases really I think both are good.
That's not really true. Ffmpeg is a Swiss army knife for anything related to digital multimedia (old and new). It is broken into a few libraries but doesn't really have plugins.
Gstreamer has a different model, chaining together plugins. Lots of overlap, but I think Gstreamer only has real traction because some silicon vendors use it.
GStreamer is just a different front end to ffmpeg.
ffmpeg's core functionality (encode, decode, streams, pipes, channels) are all implemented in `libav` which gstreamer links against.
GStreamer doesn’t use ffmpeg’s pipeline at all. It implements a much more advanced directed graph with disconnect, connection and pad negotiation. You can dynamically swap out the entire filter graph during live playback with zero disruption. Swap feeds, outputs, effects… all at runtime.
ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines. You can use “switcher” components but the inputs are still static.
GStreamer is extremely special. The only thing that comes close was Microsoft’s DirectShow, which has since been replaced with Media Foundation which can’t do it. And while DirectShow did support it, it was fragile because many 3rd party filters did not support dynamic configuration.
GStreamer does use ffmpeg, but it just wraps the core encoder/decoder/filter code and discards the streams/graph/pipe part of ffmpeg.
2 replies →
GStreamer is not "just a different front end to ffmpeg". GStreamer is a pluggable media graph system.
"GStreamer" doesn't link against libav. The GStreamer plugin "gst-libav" links against libav. If you're not using the gst-libav, you're not using ffmpeg. I'd bet a relatively small amount of GStreamer use cases use gst-libav; I typically see people use e.g x264dec and x264enc (from the x264 plugin) to decode and encode media, or, for hardware encoding/decoding, the v4l2enc and v4l2dec elements (or elements from a SoC vendor's plug-in such as gst-rockchip). It also has its own non-libav elements to handle container formats, pixel format conversion, scaling, etc, which are more natural to use since they're part of the core gstreamer plug-in packages rather than gst-libav.
Doesn't GStreamer mostly use ffmpeg plugins?
In my experience it's mainly run by very grumpy and opinionated Europeans who take pride in having bugs old enough to drink.
> Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content.
You would change your opinion quickly if your browser, apps and TV suddenly stopped supporting videos due to relying on FFmpeg.
What prevents running a data stream in, transcoded data out sandbox with no access to unlimited resources, system files, system stacks, etc.
It's okay for a sandbox to fall over due to bad inputs and poor memory security if it can just be restarted and move onto other streams.
I think Chromium already does sandbox ffmpeg in the renderer process because of their "Rule of Two": https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
Thus:
1. Code which processes untrusted input
2. Code written in unsafe languages like C or C++
3. Code that runs without a sandbox
So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.
4 replies →
Most of them require hardware acceleration from the CPU or GPU and that can potentially be exploited to escape the sandbox. GPUs in particular are difficult to sandbox.
Time to RIIR, then?
I haven't seen that acronym before, but my guess is that it's "Re-Implement In Rust", right?
Usually it's Rewrite it in Rust, but both work I guess
[flagged]
[flagged]
Pretty bad astroturfing
ffmpeg is also rather popular and delivers a lot of functionality. Its unlikely that you don't have it installed.
Yes, there are security issues but quite a few are not ffmpeg itself related - the input is pretty shabby or at least not exactly easy to deal with!
Obviously, they could do with some assistance and I'm sure you and I will both dive in with equal zeal.
Hmm.. "shabby input" that makes software xyz fail is a problem in software xyz itself!
"Validate your inputs" is a common rule. Fuzzing is a thing. Both for good reasons (including security).
The obvious question is, how many of those were the sort that writing in a memory-safe language would make impossible?
They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.
Rewriting ffmpeg in Rust will not solve it. The parts that are memory unsafe in ffmpeg, and similar projects, are not unsafe because C or C++ is inherently unsafe. Instead, it's the CODE that is unsafe. Translating the code (data structures, logic, etc) to Rust does not fix bugs in the code. That code will be littered with "unsafe" code, and of course, it will no longer be maintainable.