Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty One Zero-Days in FFmpeg

depthfirst.com

Post reply on HN
Print view View original

71–80 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#71

Post by tptacek »

naturalmovement wrote: post #62
bawolff wrote: post #61

Earlier quoted context omitted.

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

Security is a bit different. Today it's an industry driven by unscrupulous clout-chasers and a commitment to quantity over quality. There is a difference between going through patches and pull requests vs. the endless stream of LLM-assisted bullshit that has started cluttering security inboxes in the last few years.

Vulnerability researchers don't create the vulnerabilities they report. The vulnerabilities exist whether or not they're reported by "clout chasers".

Re: Twenty One Zero-Days in FFmpeg

#72

Post by anon-3988 »

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

[flagged]

Re: Twenty One Zero-Days in FFmpeg

#73

Post by woodruffw »

lostglass wrote: post #55
woodruffw wrote: post #31

Earlier quoted context omitted.

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

Speed and security are not good bedfellows. Combine that with really shitty standards and dozens of years of development... Oh, and licensing. Licensing is the real killer. I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.

I don’t think this is necessarily true! Constraints can be liberating: a language that allows strong encoding of invariants makes it easier for the language’s compiler to optimize.

I agree about long periods of development and difficult standards, though.

Re: Twenty One Zero-Days in FFmpeg

#74

Post by duped »

loeg wrote: post #23
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.…

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

One dude running an X account is not indicative of a community to be honest.

That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.

Re: Twenty One Zero-Days in FFmpeg

#76

Post by wavemode »

oinoom wrote: post #68
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.…

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

Security vulnerabilities are less about programming ability and more about rigor.

Re: Twenty One Zero-Days in FFmpeg

#77

Post by hugmynutus »

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

Re: Twenty One Zero-Days in FFmpeg

#78

Post by Terr_ »

jacobgold wrote: post #7

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

I glumly predict that copyright-holding companies wanting DRM, "trusted platforms", regulatory capture, etc. will drive some of the damage here.

Secure sandboxing tends to mean opportunities to make unrestricted copies.

Re: Twenty One Zero-Days in FFmpeg

#79

Post by boomlinde »

duped wrote: post #74
loeg wrote: post #23

Earlier quoted context omitted.

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

One dude running an X account is not indicative of a community to be honest. That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.

I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.

Re: Twenty One Zero-Days in FFmpeg

#80

Post by derf_ »

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?

Any multimedia project trying to support a large number of formats, whose usage in the wild differs by orders of magnitude, is going to have code of varying quality (although quality is not strictly correlated with usage: age and complexity are also big factors, among others). GStreamer puts plugins into different categories (-good, -bad, etc.) based on things like the maturity of the code, which helps you judge what risks you are taking. With FFmpeg it is harder to know which formats are more likely to have issues. Of course GStreamer can use FFmpeg, in which case you will also have all of FFmpeg's problems.

In both cases you are best off restricting things to what you actually use.

Post reply on HN