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

191–200 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#191

Post by duped »

boomlinde wrote: post #79
duped wrote: post #74

Earlier quoted context omitted.

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.

The main beef is the noise created around these disclosures instead of sending patches to fix the bugs.

Re: Twenty One Zero-Days in FFmpeg

#192

Post by preg_match »

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 is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain.

It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.

Re: Twenty One Zero-Days in FFmpeg

#193

Post by preg_match »

Gehinnn wrote: post #9
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…

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?

No, browsers have had many sandbox escape exploits related to decoding.

Re: Twenty One Zero-Days in FFmpeg

#194

Post by notenlish »

naturalmovement wrote: post #37
bawolff wrote: post #35

Earlier quoted context omitted.

> nearly inexhaustible supply of LLM slop daily, Actual well written vulnerability reports are not the same as slop. AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop. Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.

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

Its not as full featured as ffmpeg but I remember hearing about mediabunny, It's a web native ffmpeg alternative, and according to its website, seems to be a lot faster than ffmpeg.wasm

Re: Twenty One Zero-Days in FFmpeg

#195

Post by TD-Linux »

m4rtink wrote: post #135
jstanley wrote: post #132

Earlier quoted context omitted.

Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up. They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used. I was left w…

Is it really available in practice ? Eg. do major distros even compile ffmpeg with these obscure codecs or you need to recompile it yourself to get it ?

Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.

Re: Twenty One Zero-Days in FFmpeg

#196

Post by lostglass »

throwaway2037 wrote: post #140
lostglass wrote: post #55

Earlier quoted context omitted.

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 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 am confused. > The MP3 format is now patent-free and requires no licensing fees to distribute or use. Fraunhofer IIS and Technicolor officially terminated their MP3 licensing programs, with all core patents having expired. Anyone can encode, decode, and distribu…

Sorry I was painting a broad image. I'm also worried about copyright infringement, discovery, someone switching to a different different that requires glpl, etc

Re: Twenty One Zero-Days in FFmpeg

#197

Post by nulltype »

preg_match wrote: post #192
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 is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain. It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.

For the implemented formats, wuffs is safer and also often faster: https://github.com/google/wuffs

Re: Twenty One Zero-Days in FFmpeg

#198

Post by dspillett »

tptacek wrote: post #175
dspillett wrote: post #162

Earlier quoted context omitted.

There is a difference between a proper vulnerability researcher and a clout chaser calling themselves a vulnerability researcher. Research for a start, to assess the problem to see if it is genuine and if so if there are significant mitigating factors (by default or that can be implemented), and checking if it hasn't already been reported, instead of just copypasting some LLM output with minimal review. And to many c…

No there isn't. The vulnerability is either real or it isn't. How you feel about the researchers doesn't enter into it. People angry about vulnerability research have been making this argument since 1992.

> No there isn't.

Yes there is, because:

> The vulnerability is either real or it isn't.

this, exactly: sometimes the vulnerability isn't, or isn't a fraction as serious as it is made out to be because it doesn't affect any sane configuration. And the project contributors don't know this until they've wasted time looking into it, time that could be spent looking into actual serious problems.

The extra problem right now is several people/groups dropping the same set of vulnerabilities with not coordination because they've got this great new tool to garner attention and want to be first. So projects have several things to look into that turn out to be exactly the same thing.

Re: Twenty One Zero-Days in FFmpeg

#199

Post by akerl_ »

dspillett wrote: post #198
tptacek wrote: post #175

Earlier quoted context omitted.

No there isn't. The vulnerability is either real or it isn't. How you feel about the researchers doesn't enter into it. People angry about vulnerability research have been making this argument since 1992.

> No there isn't. Yes there is, because: > The vulnerability is either real or it isn't. this, exactly: sometimes the vulnerability isn't , or isn't a fraction as serious as it is made out to be because it doesn't affect any sane configuration. And the project contributors don't know this until they've wasted time looking into it, time that could be spent looking into actual serious problems. The extra problem right…

Nobody is obligating open source maintainers to accept or read these reports.

Re: Twenty One Zero-Days in FFmpeg

#200

Post by throwaway2037 »

lostglass wrote: post #196
throwaway2037 wrote: post #140

Earlier quoted context omitted.

> 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 am confused. > The MP3 format is now patent-free and requires no licensing fees to distribute or use. Fraunhofer IIS and Technicolor officially terminated their MP3 licensing programs, with all core patents having expired. Anyone can encode, decode, and distribu…

Sorry I was painting a broad image. I'm also worried about copyright infringement, discovery, someone switching to a different different that requires glpl, etc

You raise a good point. You can substitute "MP3" with any patent-/copyright-/license-laden important media codec and you will face the same issues. Your comment would be very timely in the year 2005, when MP3 licensing was a serious issue for game devs.
Post reply on HN