Twenty One Zero-Days in FFmpeg • Hacker News Board

Re: Twenty One Zero-Days in FFmpeg

#121

Post by Rygian » Sat, Jun 13, 2026, 7:24 AM UTC

guessmyname wrote: post #93

I think the industry is optimizing for the wrong thing. Generating thousands of AI-written bug reports is easy, at least with Mythos (preview 1) or GPT-5.5. Getting bugs fixed is the hard part. A few months ago I started working on a system that finds critical security issues and opens PRs instead of just filing reports. The acceptance rate is sitting at roughly 94% so far. Most of the failures were due to project-sp…

> I think the industry is optimizing for the wrong thing.

Indeed: The industry optimizes for speed, time to market, and features, and applies the ostrich model to everything that doesn't bring short-time revenue (security considerations, accessibility, vendor lock-in, interoperability, …)

This has been going on for as long as the industry exists, and now we start to have the proper tools to assess the damage and understand the brittleness of it all.

Re: Twenty One Zero-Days in FFmpeg

#122

Post by perlgeek » Sat, Jun 13, 2026, 7:36 AM UTC

journal wrote: post #120

da_chicken wrote: post #28

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

Explain what it means along with your statement. Maybe I have the wrong definition too.

(not op)

If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication.

When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.

Re: Twenty One Zero-Days in FFmpeg

#123

Post by fpoling » Sat, Jun 13, 2026, 7:40 AM UTC

ttoinou wrote: post #13

johnnythunder wrote: post #8

Earlier quoted context omitted.

One chained sandbox escape away from compromise.

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

For executables on Linux there are things like bubblewrap or firejail. One can also use a restrictive container. But those are strictly weaker than browser sandboxes.

The most secure way presently is to use qubes-os that allows to use a very hardened VM to run individual applications.

Re: Twenty One Zero-Days in FFmpeg

#124

Post by hdgvhicv » Sat, Jun 13, 2026, 7:46 AM UTC

KPGv2 wrote: post #63

insanitybit wrote: post #38

Earlier quoted context omitted.

https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw... Security is the punch line for ffmpeg.

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.

Back in 2004 when free email services like hotmail were limited to 10-15mb, on April 1st the evening standard front page headline, which I saw in the office around 2pm, was something “Google lunched 1gb email”

I couldn’t believe they had fallen for an April fools so hard.

Re: Twenty One Zero-Days in FFmpeg

#125

Post by samiv » Sat, Jun 13, 2026, 7:56 AM UTC

nerdsniper wrote: post #33

zerobees wrote: post #19

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

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

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.

Re: Twenty One Zero-Days in FFmpeg

#126

Post by cubefox » Sat, Jun 13, 2026, 8:01 AM UTC

defrost wrote: post #115

cubefox wrote: post #111

Earlier quoted context omitted.

Am I getting this right, you expect TVs which are running Google TV (Android TV is the old name) to be less secure than TVs which are running a different operating system? I think the opposite is the case, because Google TV is developed by Google, which has a lot of experience with software security, while other TV operating systems are developed by companies which clearly don't have that experience.

There are a lot of "Android like" TVs out there.

Those are running mainly on Google TV. Tizen or webOS are also common but are not based on Android.

Re: Twenty One Zero-Days in FFmpeg

#127

Post by simjnd » Sat, Jun 13, 2026, 8:03 AM UTC

zerobees wrote: post #19

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

Re: Twenty One Zero-Days in FFmpeg

#128

Post by mr_mitm » Sat, Jun 13, 2026, 8:06 AM UTC

HappMacDonald wrote: post #118

zerobees wrote: post #109

Earlier quoted context omitted.

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 vi…

So all I am hearing is.. Rust

My understanding is that ffmpeg is probably incredibly close to the metal, with tons of assembler mixed in. I imagine doing the same in Rust would include lots of `unsafe` blocks and a similar amount of assembly, so it wouldn't change much in terms of security. Or am I wrong?

Re: Twenty One Zero-Days in FFmpeg

#129

Post by imjonse » Sat, Jun 13, 2026, 8:10 AM UTC

zerobees wrote: post #19

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

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.

Re: Twenty One Zero-Days in FFmpeg

#130

Post by [deleted] » Sat, Jun 13, 2026, 8:22 AM UTC

lkt wrote: post #84

loeg wrote: post #23

Earlier quoted context omitted.

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

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

[deleted]