Live data from Hacker News

Twenty One Zero-Days in FFmpeg

depthfirst.com

81–90 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#81

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

[flagged]

Pretty bad astroturfing

Re: Twenty One Zero-Days in FFmpeg

#82

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.

You would change your opinion quickly if your browser, apps and TV suddenly stopped supporting videos due to relying on FFmpeg.

Re: Twenty One Zero-Days in FFmpeg

#83
post #82

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

Re: Twenty One Zero-Days in FFmpeg

#84
post #23

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

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

Re: Twenty One Zero-Days in FFmpeg

#85
post #61

Earlier quoted context omitted.

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

> Ok but who is going to sift through it all to triage the good bits when you're working on something for free? Its like anything else in open source. Maintainers will do so if they care. Maybe they decide they don't care. That is always their decision to make but there are consequences for the project. Maybe those consequences make sense. Being a maintainer is all about making cost-benefit trade offs. > Who gives a…

Yes, and people will sit there and sip tea while waiting for "someone"? For how long?

Re: Twenty One Zero-Days in FFmpeg

#86

Earlier quoted context omitted.

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

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.

Re: Twenty One Zero-Days in FFmpeg

#87
post #68

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

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

[flagged]

Re: Twenty One Zero-Days in FFmpeg

#88

Earlier quoted context omitted.

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

> the difference between a vulnerability and an exploit is it the difference between a knife and a stab wound?

No, that's the difference between exploit (knife) and either the incident or impact (wound). The vulnerability would be a gap in armor.

The vulnerability is the exposed weakness. Vulnerabilities get fixes, and they exist without anybody knowing about them. Vulnerabilities get CVEs assigned to them.

The exploit is the means of attack. It's the specific actions or calls that let you take advantage of a vulnerability. It could be a worm, or botnet scripts, or specifically crafted data[0]. A proof of concept is not an exploit itself, but it demonstrates that the vulnerability can be exploited.

An example of a vulnerability might be a gate where the gap between the door and the jam are too wide. The exploit is a coat hanger used to lift the inside latch from outside the gate. That results in unprivileged access.

And zero-day specifically compares when the white hats (vendors, system owners) and the black hats learn about the existence of a vulnerability. If white hats learn that a vulnerability exists by being subject to an in-the-wild black hat exploit of it, then it's a true zero-day.

[0]: https://xkcd.com/327/

Re: Twenty One Zero-Days in FFmpeg

#89
post #23

Earlier quoted context omitted.

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

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

Re: Twenty One Zero-Days in FFmpeg

#90

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

Time to RIIR, then?
Post reply on HN