[afiori]

This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it.

In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix

[esrauch]

This program discloses security issues to the projects and only discloses them after they have had a "reasonable" chance to fix it though, and projects can request extensions before disclosure if projects plan to fix it but need more time.

Google runs this security program even on libraries they do not use at all, where it's not a demand, it's just whitehat security auditing. I don't see the meaningful difference between Google doing it and some guy with a blog doing it here.

[XorNot]

Google is a multi-billion dollar company, which is paying people to find these bugs in the first place.

That's a pretty core difference.

[tpmoney]

Great, so Google is actively spending money on making open source projects better and more secure. And for some reason everyone is now mad at them for it because they didn't also spend additional money making patches themselves. We can absolutely wish and ask that they spend some money and resources on making those patches, but this whole thing feels like the message most corporations are going to take is "don't do anything to contribute to open source projects at all, because if you don't do it just right, they're going to drag you through the mud for it" rather than "submit more patches"

[samus]

Why should Google not be expected to also contribute fixes to a core dependency of their browser, or to help funding the developers? Just publishing bug reports by themselves does not make open source projects secure!

[walletdrainer]

Google does do that.

This bit of ffmpeg is not a Chrome dependency, and likely isn’t used in internal Google tools either.

> Just publishing bug reports by themselves does not make open source projects secure!

It does, especially when you first privately report them to the maintainers and give them a plenty of time to fix the bug.

[Orygin]

It doesn't if you report lots of "security" issues (like this 25 years old bug) and give too little time to fix them.

Nobody is against Google reporting bugs, but they use automatic AI to spam them and then expect a prompt fix. If you can't expect the maintainers to fix the bug before disclosure, then it is a balancing act: Is the bug serious enough that users must be warned and avoid using the software? Will disclosing the bug now allow attackers to exploit it because no fix has been made?

In this case, this bug (imo) is not serious enough to warrant a short disclosure time, especially if you consider *other* security notices that may have a bigger impact. The chances of an attacker finding this on their own and exploiting it are low, but now everybody is aware and you have to rush to update.

[khannn]

They're actively making open source projects less secure by publishing bugs that the projects don't have the volunteers to fix

I saw another poster say something about "buggy software". All software is buggy.

[tpmoney]

The bug exists whether or not google publishes a public bug report. They are no more making the project less secure than if some retro-game enthusiast had found the same bug and made a blog post about it.

[saagarjha]

Publishing bugs that the project has so that they can be fixed is actively making the project more secure. How is someone going to do anything about it if Google didn’t do the research?

[khannn]

Did you see how the FFMPEG project patched a bug for a 1995 console? That's not a good use for the limited amount of volunteers on the project. It actively makes it less secure by taking away from more pertinent bugs.

[troupo]

> so Google is actively spending money on making open source projects better and more secure

It looks like they are now starting to flood OSS with issues because "our AI tools are great", but don't want to spend a dime helping to fix those issues.

xkcd 2347

[tpmoney]

According to the ffmpeg maintainer's own website (fflabs.eu) Google is spending plenty of dimes helping to fix issues in ffmpeg. Certainly they're spending enough dimes for the maintainers to proudly display Google's logo on their site as a customer of theirs.

[troupo]

Here's ffmpeg's site: https://www.ffmpeg.org

I fail to see a single Google logo. I also didn't know that Google sonehow had a contract with ffmpeg to be their customer.

[thevillagechief]

Corporate Social Responsibility? The assumption is that the work is good for end users. I don't know if that's the case for the maintainers though.

[toast0]

The user is vulnerable while the problem is unfixed. Google publishing a vulnerability doesn't change the existence of the vulnerability. If Google can find it, so can others.

Making the vulnerability public makes it easy to find to exploit, but it also makes it easy to find to fix.

[tremon]

If it is so easy to fix, then why doesn't Google fix it? So far they've spent more effort in spreading knowledge about the vulnerability than fixing it, so I don't agree with your assessment that Google is not actively making the world worse here.

[toast0]

I didn't say it was easy to fix. I said a publication made it easy to find it, if someone wanted to fix something.

If you want to fix up old codecs in ffmpeg for fun, would you rather have a list of known broken codecs and what they're doing wrong; or would you rather have to find a broken codec first.

[BobaFloutist]

>If Google can find it, so can others.

What a strange sentence. Google can do a lot of things that nobody can do. The list of things that only Google, a handful of nation states, and a handful of Google-peers can do is probably even longer.

[toast0]

Sure, but running a fuzzer on ancient codecs isn't that special. I can't do it, but if I wanted to learn how, codecs would be a great place to start. (in fact, Google did some of their early fuzzing work in 2012-2014 on ffmpeg [1]) Media decoders have been the vector for how many zero interaction, high profile attacks lately? Media decoders were how many of the Macromedia Flash vulnerabilities? Codecs that haven't gotten any new media in decades but are enabled in default builds are a very good place to go looking for issues.

Google does have immense scale that makes some things easier. They can test and develop congestion control algorithms with world wide (ex-China) coverage. Only a handful of companies can do that; nation states probably can't. Google isn't all powerful either, they can't make Android updates really work even though it might be useful for them.

[1] https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...

[om2]

Nation-states are a very relevant part of the threat model.

[nmz]

> If Google can find it, so can others.

While true, Only Google has google infrastructure, this presupposes that 100% of all published exploits would be findable.

[chii]

you'd assume that a bad actor would have found the exploit and kept it hidden for their own use. To assume otherwise is fundamentally flawed security practice.

[betaby]

> If Google can find it, so can others.

Not really. It requires time, ergo money.

[chii]

which bad actors would have more of, as they'd have a financial incentive to make use of the found vulnerabilities. White hats don't get anything in return (financially) - it's essentially charity work.

[om2]

In this world and the alternate universe both, attackers can also use _un_published vulnerabilities because they have high incentive to do research. Keeping a bug secret does not prevent it from existing or from being exploited.