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:
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.
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.
> 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.
>The reach of this bug is what makes it serious. Any deployment that points FFmpeg at an attacker-influenced RTSP URL is exposed: media ingest pipelines fetching user-supplied stream URLs, surveillance and CCTV systems pulling RTSP feeds, and transcoding services processing remote AV1-over-RTP sources
Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can imagine this is exploitable today.
Some people might suggest it’s crucial to publish if you’re aware of a serious vulnerability, so that people using the software in a vulnerable way can take steps to mitigate the risk.
> At this point the corrupted free pointer is called, and control of the instruction pointer is ours.
Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
The article glosses over this, but it looks like the next variable in the struct is conveniently the first parameter to the function, so you can run arbitrary code with system() or whatever. But, yeah, you would need some other exploit to defeat ASLR.
Inflated use of the term zero-day, while none of the described vulnerabilities is actually a zero-day. But it sounds and clicks good..
thank you for the PoC.
Is the future of defense-against-foreign-agents-on-my-codebase to subtly hide prompt injections into one’s codebase that would defeat agents to find security bugs ?
If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
What about VLC's own built-in versions of decoding libraries (I think, from the FFmpeg project)? Is there a scenario here where we may have to deal with malicious MP4 files?
I've been using ffmpeg for a very long time, both personally and for services I've built. Fabrice Bellard is a genius, and the developers who have taken it so far have made the world measurably richer.
But I can't think of a program more worthy of sandboxing when run with untrusted input than ffmpeg. It's a huge amount of C dealing with the most complicated video and audio codecs, which is notoriously impossible to get completely right.
But it's not actually that big of a problem. I run ffmpeg inside a VM or gVisor, and the end result is usually a video file that I'm perfectly willing to play in my browser, where it gets decoded in yet another sandbox because this shit is hard.
What do you mean "video file that I'm perfectly willing to play in my browser". Isn't it safe to assume that no video file can escape the browser decoding sandbox?
I'm not up-to-speed with the current state of sandboxing in browsers, but in principle it's (on modern operating systems) not especially hard for them to sandbox the decoding into a separate process with basically no privileges beyond rendering a video stream. It's a bit trickier if we're only considering demuxing and delegating decoding to the hardware, but that's a much smaller attack surface.
A manually run ffmpeg on the command line does nothing to restrict its privileges, and its security model has very little interest in doing so, while browsers very much have.
"No way to prevent this" say users of only language where this regularly happens, etc, etc. Several of these bugs do not appear to be in hot code and would have been detected by a language with saner behaviour.
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.
Security is the punch line for ffmpeg.
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.
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.
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.
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.
Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can imagine this is exploitable today.
(There are a number of reasons for this, not least being that C makes it very easy to ship partially initialized memory over the wire.)
Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.
If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
What about "ls"?
But I can't think of a program more worthy of sandboxing when run with untrusted input than ffmpeg. It's a huge amount of C dealing with the most complicated video and audio codecs, which is notoriously impossible to get completely right.
But it's not actually that big of a problem. I run ffmpeg inside a VM or gVisor, and the end result is usually a video file that I'm perfectly willing to play in my browser, where it gets decoded in yet another sandbox because this shit is hard.
Why would that be safe to assume? If that were a reasonable assumption, you could just as well assume that it's safe to run ffmpeg.
A manually run ffmpeg on the command line does nothing to restrict its privileges, and its security model has very little interest in doing so, while browsers very much have.
Another option is WASM or WASM-style sandboxes if using another process is undesirable.
But are the compiler+OS that runs the ffmpeg executable really a sandbox ?