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

151–160 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#151

Post by dspillett »

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.

I wouldn't call "nice find, care to help us fix that?" extremely hostile. It can be frustrating for open source projects that far more people want a pat on the back for the identification of a problem (be it security, performance, documentation, or anything else) than there are people who have the time and inclination to help resolve the issue (or ability and inclination to fund the project so it can more easily find help if needed). The use of LLM based tools apparently making that pat on the back easier to attain is going to exacerbate that problem for a while at least.

Re: Twenty One Zero-Days in FFmpeg

#152

Post by [deleted] »

lostglass wrote: post #56
Denvercoder9 wrote: post #20

Earlier quoted context omitted.

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…

Yeah, then you need to stream content in real time between multiple processes. And not screw up the licensing. And get hardware acceleration working...

[deleted]

Re: Twenty One Zero-Days in FFmpeg

#153

Post by anoneng »

acdha wrote: post #144
cryo32 wrote: post #138

Earlier quoted context omitted.

No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.

coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake. In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with…

I would say it’s the opposite. coreutils is core utils, you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. They are also relatively simple.

With ffmpeg, anyone who knows anything about secure application development in the past 20 years knows that it is a huge security tarpit and throwing it untrusted inputs in trusted environment is asking to be owned. You thoroughly sandbox that shit. That’s true for all untrusted media conversion, but absolutely with ffmpeg.

Re: Twenty One Zero-Days in FFmpeg

#154

Post by krageon »

bawolff wrote: post #35
naturalmovement wrote: post #30

Earlier quoted context omitted.

[flagged]

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

Even before the advent of AI the quality of most reports was depressingly low. Most of your reports will quite simply come from folks in lower-wage countries that broadly don't speak English well and that use a shotgun approach to bug bounties. That means you are receiving a lot of them, they will be hard to read (assuming the information you need is in there at all) and if they get one success out of fifty then for them it is a really good return.

The advent of LLMs has made this a hundred times worse. Both because it makes it easier for most people to create reports that sound good (and so are more effort to dissect) and because people who didn't have to work hard to get any amount of competence are usually more entitled and more rude (the stakes are even lower for them).

It is economically no longer a good idea to run a bug bounty program at all. I honestly question whether or not even having a direct input for such things makes any sense anymore. The volume is becoming so great you need a classical spam filter to plow through it. But that won't work, because they all sound reasonable.

Re: Twenty One Zero-Days in FFmpeg

#155

Post by dspillett »

endofreach wrote: post #102
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.…

Of course. Everybody knows to rather use the obvious alternative to ffmpeg!

> the obvious alternative to ffmpeg

IIRC that is currently sandboxed ffmpeg.

Until the people going on about making an equivalent in pure rust being automatically much safer, stop talking about it and actually get on with making it, of course!

Re: Twenty One Zero-Days in FFmpeg

#157

Post by RetroTechie »

franga2000 wrote: post #136
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…

The user is not free to use whatever codec they want. Many niche codecs can't be put into the usual containers, so if you only accept QuickTime/MP4 and AVI, sometimes even just by limiting the file extension, those codecs can't be used. If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up. It would be nice if you could do that, but that's no…

> If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up.

Isn't that what fuzzing and input validation is about? Most bugs presented in article suggest failures in the latter.

Re: Twenty One Zero-Days in FFmpeg

#158

Post by dspillett »

bawolff wrote: post #61
naturalmovement wrote: post #37

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…

> Maintainers will do so if they care.

Caring is only part of the problem. If you are inundated by low quality reports, or many duplicates of what turn out to effectively be the same problem, that you have to sift through to find the useful reports, then by the time you have something actionable you have no time left to take action on it.

The amount of reports coming in, particularly the low/zero quality ones, is apparently growing at a much faster rate than the time volunteers have for dealing with them.

Caring does not magically solve problems without enough people with enough time.

Re: Twenty One Zero-Days in FFmpeg

#159

Post by BoingBoomTschak »

teravor wrote: post #114
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.…

while sandboxing ffmpeg directly isn't difficult, unfortunately with something like MPV/VLC that uses ffmpeg it's more challenging. until recently (virtio gpu native context) it wasn't even possible to sandbox a video player without losing all hardware acceleration. at least not from the outside, they could always try to sequester ffmpeg and seccomp it to hell like chromium.

Sandboxing not only OS access but also hardware access feels almost impossible to be honest. At least not via user-friendly exec based stuff like bwrap.

Personally, I still try to contain them a bit: https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles

Re: Twenty One Zero-Days in FFmpeg

#160

Post by ftchd »

LegionMammal978 wrote: post #147
simjnd wrote: post #127

Earlier quoted context omitted.

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.

On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through. Now, personally, when I file a bug report for a FOSS project I like to suggest an u…

If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.
Post reply on HN