Twenty One Zero-Days in FFmpeg(depthfirst.com) |
Twenty One Zero-Days in FFmpeg(depthfirst.com) |
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.
I agree. I work for InstaVM which essentially gives you sandboxes - so I can share some perspective from the other side.
The trend is that people are building AI agents and these agents almost always have a chat box, so prompt injections are always a threat apart from the usual hallucinations or wrong code generated by the llm. Not everyone wants to give latest and great AI models to their users due to cost so end up with something like Gpt-4o and rm rf-ing the whole thing at times. At this point you have to use an isolated environment to guard against these.
Security is the punch line for ffmpeg.
Do you have an example?
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.
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.
I understand why it's poorly understood. It's a snappy term, and people assume it means "bad" and nothing else because that's all you can get from the context. However, since most people also don't know the difference between a vulnerability and an exploit, they won't understand the definition of a zero-day when they read it.
But I'm still going to complain if a security vulnerability research company is using the term incorrectly in their own press copy. It makes them look amateurish.
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
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.
LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.
What about "ls"?
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 ?
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.