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

781–790 of 913 posts

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

#781

Post by theoldgreybeard »

tpmoney wrote: post #417
theoldgreybeard wrote: post #72

The vulnerability in question is a Use After Free. Google used AI to find this bug, it would've taken them 3 seconds to fix it. Burning cash to generate spam bug reports to burden volunteer projects when you have the extra cash to burn to just fix the damn issue leaves a very sour taste in my mouth.

If it takes 3 seconds to fix it, then how is this some massive burden on the maintainers? The bug report pointed to the relevant lines, the maintainers are the most familiar with the code and it probably would have taken them 1.5 seconds to not only fix it, but validate the fix. It probably took more time to write up the complaint about the bugs than to implement the fix.

I’m not on the beck and call of Google’s robot.

Maybe if it was an actual engineer from Google doing this they would have gotten a better response. Don’t expect people to treat AIs the same way we treat people.

But if you send me an automated report and then tell me to jump I’m telling you to f*ck off.

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

#782

Post by adgjlsfhk1 »

godelski wrote: post #512
rossjudson wrote: post #460

Earlier quoted context omitted.

I'm sure that a hacker wouldn't think of trying to use an obscure format... https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

> If you used the scan to pdf functionality of a [Xerox] like this a decade ago, your PDF likely had a JBIG2 stream in it. That's not an obscure format, that's an old format. Meanwhile with ffmpeg we're talking about > decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995. That's both old and obscure . Your point is still taken, but just to clarify that these are dif…

The problem is that if you have a process using ffmpeg and an attacker feeds it a video with this codec, ffmpeg will proceed to auto-detect the codec, attempt to decrypt and then then break everything.

If the format is old and obscure, and the implementation is broken, it shouldn't be on by default.

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

#783

Post by SAI_Peregrinus »

johneth wrote: post #78
Lerc wrote: post #42

Earlier quoted context omitted.

That is standard practice. It is considered irresponsible to not publicly disclose any vulnerability. The X days is a concession to the developers that the public disclosure will be delayed to give them an opportunity to address the issue.

> That is standard practice. It's standard practice for commercially-sponsored software, and it doesn't necessarily fit volunteer maintained software. You can't have the same expectations.

You disclose so that users can decide what mitigations to take. If there's a way to mitigate the issue without a fix from the developers the users deserve to know. Whether the developers have any obligation to fix the problem is up to the license of the software, the 90 day concession is to allow those developers who are obligated or just want to issue fixes to do so before details are released.

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

#784

Post by ahepp »

saagarjha wrote: post #450
ahepp wrote: post #266

Earlier quoted context omitted.

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…

Project Zero is an offensive security team. Its job is to find vulnerabilities.

In their own words:

> Our mission is to make the discovery and exploitation of security vulnerabilities more difficult, and to significantly improve the safety and security of the Internet for everyone.

> We perform vulnerability research on popular software like mobile operating systems, web browsers, and open source libraries. We use the results from this research to patch serious security vulnerabilities, to improve our understanding of how exploit-based attacks work, and to drive long-term structural improvements to security.

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

#785

Post by SAI_Peregrinus »

ekidd wrote: post #498
freedomben wrote: post #152

Earlier quoted context omitted.

I would love to see Google contribute here, but I think that's a different issue. Are the bug reports accurate? If so, then they are contributing just as if I found them and sent a bug report, I'd be contributing. Of course a PR that fixes the bug is much better than just a report, but reports have value, too. The alternative is to leave it unfound, which is not a better alternative in my opinion. It's still there an…

The actual real alternative is that the ffmpeg maintainers quit, just like the libxml2 maintainer did. A lot of these core pieces of infrastructure are maintained by one to three middle-aged engineers in their free time, for nothing. Meanwhile, billion dollar companies use the software everywhere , and often give nothing back except bug reports and occasional license violations. I mean, I love "responsible disclosure…

The other alternative if the ffmpeg developers change the text on their "about" screen from "Security is a high priority and code review is always done with security in mind. Though due to the very large amounts of code touching untrusted data security issues are unavoidable and thus we provide as quick as possible updates to our last stable releases when new security issues are found." to something like "Security is a best-effort priority. Code review is always done with security in mind. Due to the very large amounts of code touching untrusted data security issues are unavoidable. We attempt to provide updates to our last stable releases when new security issues are found, but make no guarantees as to how long this may take. Priority will be given to reports including a proof-of-concept exploit and a patch that fixes the security bug."

Then point to the "PoC + Patch or GTFO" sign when reports come in. If you use a library with a "NO WARRANTY" license clause in an application where you're responsible for failures, it's on you to fix or mitigate the issues, not on the library authors.

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

#786

Post by cyberrock »

mrkiouak wrote: post #721
andriamanitra wrote: post #720

As much as I hate to be on Google's side I think they're doing a reasonable thing here. Valid bug reports are valuable contributions on their own, and disclosing security issues is standard practice. Not disclosing them doesn't help anyone. Security through obscurity is not security. If neither FFMPEG nor Google dedicate resources to fixing the issue in 90 days, making it public at least ensures that it gets visibili…

As someone who worked as a software engineer at Google on a service that heavily depended on FFmpeg, its absurd that Google posts security bugs (which have the obvious potential outcome of driving more free work) vs just paying an engineer to fix the bug. I promise they are spending more on extra compute for resiliency and redundancy for FFMPEG issues than it would cost for a single SWE to just write a fix and then s…

As someone who was on a project that stalled for a year because our patchset wasn't accepted by a different open source project (not Linux either), I can tell you from experience that it's not as easy as folks here make it out to be. Some maintainers (and Googlers) really want you to study at their mountaintop monastery before your code is worthy, and scrutiny is even higher now due to AI, as we can see from the complaints about this bug report. Now, I've merged enough open source patches on my personal time to know that most projects aren't like that, but based on this interaction, I seriously wonder if Google's patch would've been accepted without incident.

Maybe AmaGoogSoft deserves this, but then what's the threshold? If I'm in charge of Zoom or Discord and one of my engineers finds a bug, should I let them report it and risk a public blow-up? Or does my company's revenue need to be below $1B? $100M? This just poisons the well for everyone.

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

#787

Post by okayjustonemore »

fukka42 wrote: post #722
WesolyKubeczek wrote: post #701

Earlier quoted context omitted.

I don't know. The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life. Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism…

Being allowed to contribute to open source is a privilege, not a right. You could also just pay for it.

“Pay my way or take the highway” is as close to the closed-source ethos as you can possibly get. Collaboration is not feasible if the barrier of entry is too high and those involved make no effort to foster a collaborative environment.

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

#788

Post by woodruffw »

seb1204 wrote: post #711
inkysigma wrote: post #301

Earlier quoted context omitted.

I don't think that's an accurate description of the full scope of the problem. The codec itself is mostly unused but the code path can possibly be triggered from file fuzzing that ffmpeg uses so a maliciously crafted payload (e.g. any run of ffmpeg that touches user input without disabling this codec) could possibly be exploited.

Why does google simply build their own ffmpeg from source without the codec?

They almost certainly do. But it's also in the public interest to responsibly disclose vulnerabilities in components that don't directly affect you.

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

#789

Post by jsnell »

cestith wrote: post #755
esrauch wrote: post #321

Earlier quoted context omitted.

Right, Google absolutely should fund ffmpeg. But opening security issues here is not related to that in any way. It's an obscure file format Google definitely doesn't use, the security issue is irrelevant to Google's usages of it. The critique would make sense if Google was asking for ffmpeg to implement something that Google wanted, instead of sending a patch. But they don't actually care about this one, they aren't…

Opening a security issue is not the problem. A public disclosure so soon when there are so many machine-assisted reports for such obscure issues is the problem. If Google wants to force a faster turnaround on the fixes, they can send the reports with patches or they can pay for prioritization.

Three months is "soon"? What do you think is reasonable?

And like so many posters in this thread, you seem to be under the impression that Google needed this fixed at some specific timeline. In reality the fix timeline, or even a total lack of a fix, makes no impact to them. They almost certainly already disable these kinds of codecs in their build. They reported this for the good of the ecosystem and the millions of users who were vulnerable.

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

#790

Post by WesolyKubeczek »

fukka42 wrote: post #722
WesolyKubeczek wrote: post #701

Earlier quoted context omitted.

I don't know. The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life. Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism…

Being allowed to contribute to open source is a privilege, not a right. You could also just pay for it.

Thanks, I prefer that job where I am paid for writing code, not having to pay to write code.
Post reply on HN