Twenty One Zero-Days in FFmpeg

111

rredbell about 4 hours ago 47 commentsRead Article on depthfirst.com

RU version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

56% Positive

Analyzed from 1234 words in the discussion.

Discussion (47 Comments)Read Original on HackerNews

zerobees•about 3 hours 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.

mkagenius•26 minutes ago

> Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content.

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.

nerdsniper•about 2 hours ago

Is GStreamer a more secure alternative or does it just get a bit less attention than ffmpeg?

WD-42•14 minutes ago

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.

ranger_danger•31 minutes ago

In my experience it's mainly run by very grumpy and opinionated Europeans who take pride in having bugs old enough to drink.

loeg•about 2 hours ago

They're also extremely hostile to security researchers who report these issues.

insanitybit•about 2 hours ago

https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw...

Security is the punch line for ffmpeg.

grahamjperrin•about 1 hour ago

I'm glad to see their sense of humour :-)

https://nitter.net/ffmpeg/status/2039115531744334180

hootz•about 1 hour ago

Oh my god! They are so funny and memeable! gets RCE'd

grahamjperrin•about 1 hour ago

> … hostile to security researchers who report these issues.

Do you have an example?

naturalmovement•33 minutes ago

I have numerous examples of security researchers being hostile and impossible to work with (but cannot share them unfortunately).

gerdesj•about 2 hours ago

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.

nemothekid•about 4 hours ago

>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.

akerl_•about 3 hours ago

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.

skupig•about 2 hours ago

You would also need some sort of ASLR leak to make this exploitable

woodruffw•about 2 hours ago

Speaking from firsthand experience: codec and other media processing libraries are some of the easiest software to find address leaks in.

(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.)

0xbadcafebee•27 minutes ago

Even if this isn't as big a deal as this [advertisement for a security company] seems, it is a reminder that every application you release does have a security hole somewhere, and a script kiddie can now find it 5 minutes after release for $2 in credit. If you're not red-teaming your code before release, hackers are doing it after.

wavemode•about 3 hours ago

> 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.

skupig•about 2 hours ago

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.

da_chicken•about 2 hours ago

That's not what "zero-day" means.

nerdsniper•about 2 hours ago

It seems to have lost its meaning after getting popularized following Stuxnet coverage.

da_chicken•about 1 hour ago

No, I think it was since Code Red.

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.

bayouborne•about 3 hours ago

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?

jeffbee•about 2 hours ago

All media containers are potentially hostile. Any offset, extent, or reference has to be considered hostile user-provided input.

ttoinou•about 3 hours ago

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

Davidzheng•about 3 hours ago

No...

lschueller•about 2 hours ago

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.

jacobgold•about 3 hours ago

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.

Gehinnn•about 3 hours ago

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?

kjs3•5 minutes ago

Isn't it safe to assume that no video file can escape the browser decoding sandbox?

It's 'safe to assume' it's not. It's emphatically not safe to assume any mitigation is perfect.

thaumasiotes•about 3 hours ago

> Isn't it safe to assume that no video file can escape the browser decoding sandbox?

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.

Denvercoder9•about 3 hours ago

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.

ttoinou•about 3 hours ago

The parent does argues it is safer to sandbox ffmpeg yes

cyberax•about 3 hours ago

But then you also often need hardware accelerators for encoding, so you need to use C again.

kodt•41 minutes ago

Infinity - 21 is still infinity

omoikane•about 3 hours ago

Is there a timeline for each of these bugs? I wonder if these bugs had been reported to ffmpeg yet.

fizzynut•about 3 hours ago

I find difficult to know how serious the issue is, if it is even an issue.

LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.

josephg•about 1 hour ago

Its 21 issues. And they've been human validated, as far as I can tell.

tom_•about 2 hours ago

> A victim only has to run ffmpeg -i rtsp://attacker/stream, the most ordinary command imaginable

What about "ls"?

bethekidyouwant•about 4 hours ago

How does the browser use it ?unless they mean there’s a zero day in libavcodec

fpoling•about 3 hours ago

Browsers run it in a sandbox process together with allocator hardening. Most of the bugs then are just crashed of the sandbox

Another option is WASM or WASM-style sandboxes if using another process is undesirable.

johnnythunder•about 3 hours ago

One chained sandbox escape away from compromise.

loeg•about 2 hours ago

Which is of course better than zero sandbox escapes.

ttoinou•about 3 hours ago

Ahah

But are the compiler+OS that runs the ffmpeg executable really a sandbox ?

Philpax•about 2 hours ago

"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.