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

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

281–290 of 913 posts

Re: FFmpeg to Google: Fund us or stop sending bugs

#281

Post by lenerdenator »

SR2Z wrote: post #185
pjmlp wrote: post #177

Earlier quoted context omitted.

Then they can surely also provide a pull request for said CVE.

Where do you draw the line? Do you want Google to just not inspect any projects that it can't fully commit to maintaining? Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.

> Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.

Re-read the article. There's CVEs and then there's CVEs. This is the former, and they're shoving tons of those down the throats of unpaid volunteers while contributing nothing back.

What Google's effectively doing is like a food safety inspection company going to the local food bank to get the food that they operate their corporate cafeteria on just to save a buck, then calling the health department on a monthly basis to report any and all health violations they think they might have seen, while contributing nothing of help back to the food bank.

Re: FFmpeg to Google: Fund us or stop sending bugs

#282

Post by michaelt »

jeffbee wrote: post #244
dvfjsdhgfv wrote: post #239

Earlier quoted context omitted.

> "Don't come to me with problems, come with solutions" The problem is, the issue in the article is explicitly named as "CVE slop", so if the patch is of the same quality, it might require quite some work anyway.

The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1

It's a good quality bug report.

But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1]

Pretty crazy that ffmpeg supports the codec in the first place, IMHO.

I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't been used since the Clinton administration. gstreamer divides their plugins into 'good', 'bad' and 'ugly' to give them somewhere to stash unmaintained codecs.

[1] https://web.archive.org/web/20250419105551/https://wiki.mult...

Re: FFmpeg to Google: Fund us or stop sending bugs

#283

Post by phkahler »

joshkel wrote: post #148
skrebbel wrote: post #73

Earlier quoted context omitted.

How could ffmpeg maintainers kill three major AWS product lines with an email?

In a follow-up tweet, Mark Atwood eloborates: "Amazon was very carefully complying with the licenses on FFmpeg. One of my jobs there was to make sure the company was doing so. Continuing to make sure the company was was often the reason I was having a meeting like that inside the company." I interpret this as meaning there was an implied "if you screw this up" at the end of "they could kill three major product lines…

Are you interpreting that as "if we violate the license, they can revoke our right to use the software" ?? And they use it in 3 products so that would be really bad. That would make sense to have a compliance person.

Re: FFmpeg to Google: Fund us or stop sending bugs

#284

Post by lenerdenator »

ryandrake wrote: post #263
vacuity wrote: post #209

Earlier quoted context omitted.

But if it's a real, serious issue without an easy resolution, who is the burden on? It's not that the maintainers wouldn't fix bugs if they easily could. FFmpeg is provided "as is"[0], so everyone should be responsible for their side of things. It's not like the maintainers dumped their software on every computer and forced people to use it. Google should be responsible for their own security. I'm not adamant that Go…

Well, it's open source and built by volunteers, so nobody is obligated to fix it. If FFmpeg volunteers don't want to fix it or don't have the time/bandwidth to fix it, then they won't fix it. Like any other bug or CVE in any other open source project. The burden doesn't necessarily need to be on anyone.

They aren't obligated to fix CVEs until they're exploited, and then, suddenly, they very much were obligated to fix the CVEs, and their image as FLOSS maintainers and as a project are very much tarnished.

Re: FFmpeg to Google: Fund us or stop sending bugs

#285

Post by tatjam »

palata wrote: post #262
ironman1478 wrote: post #92

Never work for free. It's a complete market distortion and leads to bad actors taking advantage of you and your work.

Sometimes it's hard: for many kinds of projects, I don't think anyone would use them if they were not open source (or at least source-available). Just like I wouldn't use a proprietary password manager, and I wouldn't use WhatsApp if I had a choice. Rather I use Signal because it's open source. How to get people to use your app if it's not open source, and therefore not free? For some projects, it feels better to hav…

You can just use the GPL, then it's free, but your labour cannot be so easily profited from by big corps

Re: FFmpeg to Google: Fund us or stop sending bugs

#286

Post by jsnell »

cestith wrote: post #236
jsnell wrote: post #189

Earlier quoted context omitted.

Security is adversarial. It doesn't matter whether the users intentionally use the vulnerable codec. What matters is whether an adversary can make the users to use it. Given the codec is compiled in by default on Ubuntu, and given that IIUC the bug would already be triggered by ffmpeg's file format probing, it seems pretty likely that the answer to that is yes.

Yes, security is by definition adversarial. Thanks for the most basic lesson. How are you getting ffmpeg to process a stream or file type different from the one you’re expecting? Most use cases of ffmpeg are against known input and known output types. If you’re just stuffing user-supplied files through your tools, then yes you have a different threat model.

> How are you getting ffmpeg to process a stream or file type different from the one you’re expecting?

... That is how ffmpeg works? With default settings it auto-detects the input codec from the bitstream, and the output codec from the extension. You have to go out of your way to force the input codec and disable the auto-detection, and I don't think most software using ffmpeg as a backend would force the user to manually do it, because users can't be trusted to know those details.

Re: FFmpeg to Google: Fund us or stop sending bugs

#287

Post by saubeidl »

ahepp wrote: post #266
SR2Z wrote: post #185

Earlier quoted context omitted.

Where do you draw the line? Do you want Google to just not inspect any projects that it can't fully commit to maintaining? Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.

What is the mission of Project Zero? Is it to build a vulnerability database, or is it to fix vulnerabilities? If it's to fix vulnerabilities, it seems within reason to expect a patch. If the reason Google isn't sending a patch is because they truly think the maintainers can fix it better, then that seems fair. But if Google isn't sending a patch because fixing vulns "doesn't scale" then that's some pretty weak sauce…

To build on that - if it "doesn't scale" for one of the wealthiest companies in the world, it certainly doesn't scale for a volunteer project...

Re: FFmpeg to Google: Fund us or stop sending bugs

#288

Post by kentonv »

Honestly, I kind of think that ffmpeg should just document that it's not secure and that you're expected to run it in a sandbox if you plan to use it on possibly-malicious input. All the big cloud users and browsers are doing this already, so it would hardly even change anything.

ffmpeg is complaining that security bugs are such a drag that it's driving people away from their hobby/passion projects. Well, if fixing security bugs isn't your passion, why not just say that? Say it's not your priority, and if someone else wants it to be a priority, they can write the patches. Problem solved?

Re: FFmpeg to Google: Fund us or stop sending bugs

#289

Post by jsnell »

michaelt wrote: post #282
jeffbee wrote: post #244

Earlier quoted context omitted.

The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1

It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't b…

It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable.

The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as the common ones.

> Pretty crazy that ffmpeg supports the codec in the first place, IMHO.

Yes.

Re: FFmpeg to Google: Fund us or stop sending bugs

#290

Post by jeffbee »

michaelt wrote: post #282
jeffbee wrote: post #244

Earlier quoted context omitted.

The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1

It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't b…

Yeah but as you can see from the bug report ffmpeg automatically triggers the codec based on file magic, so it is possible that if you run some kind of network service or anything that handles hostile data an attacker could trigger the bug.
Post reply on HN