FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)

Show context

woodruffw ◴[11 Nov 25 19:16 UTC] No.45891521[source]▶

I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes perfectly fine (it’s okay for projects to decide that security isn’t a priority!), but you can’t have it both ways.

replies(13): >>45891613 #>>45891749 #>>45891930 #>>45892032 #>>45892263 #>>45892941 #>>45892989 #>>45894805 #>>45896179 #>>45897077 #>>45897316 #>>45898926 #>>45900786 #

1. xethos ◴[12 Nov 25 00:24 UTC] No.45894805[source]▶

>>45891521 #

From TFA:

> The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.”

This doesn't feel like a medium-severity bug, and I think "Perhaps reconsider the severity" is a polite reading. I get that it's a bug either way, but this leaves me with a vague feeling of the ffmpeg maintainer's time being abused.

replies(5): >>45894919 #>>45895040 #>>45895089 #>>45895618 #>>45897183 #

2. bragr ◴[12 Nov 25 00:36 UTC] No.45894919[source]▶

>>45894805 (TP) #

If it causes a crash, that's denial of service, so medium would be appropriate. But it's true that medium CVEs aren't that bad in most situations.

replies(2): >>45895057 #>>45898234 #

3. tpmoney ◴[12 Nov 25 00:49 UTC] No.45895040[source]▶

>>45894805 (TP) #

On the other hand, if the bug doesn't get filed, it doesn't get fixed. Sure Google could spend some resources on fixing it themselves, but even if they did would we not likely see a complaint about google flooding the maintainers with PR requests for obscure 30 year old codec bugs? And isn't a PR even more of a demand on the maintainer's time because now there's actual code that needs to be reviewed, tests that need to be run and another person waiting for a response on the other end?

"Given enough eyeballs, every bug is shallow" right? Well, Google just contributed some eyeballs, and now a bug has been made shallow. So what's the actual problem here? If some retro game enthusiast had filed the same but report would that be "abusing" the maintainer's time? I would think not, but then we're saying that a bug report can be "abusive" simply by the virtue of who submits it. And I'm really not sure "don't assign employees to research bugs in your open source dependencies and if you do certainly don't submit bug reports on what you find because that's abusive" is the message we want to be sending to corporations that are using these projects.

4. javier2 ◴[12 Nov 25 00:51 UTC] No.45895057[source]▶

>>45894919 #

If you need this kind of security, build ffmpeg with only decoders you find acceptable

5. woodruffw ◴[12 Nov 25 00:53 UTC] No.45895089[source]▶

>>45894805 (TP) #

I think it’s exceedingly reasonable for a maintainer to dispute the severity of a vulnerability, and to ultimately decide the severity.

replies(1): >>45896537 #

6. iscoelho ◴[12 Nov 25 02:09 UTC] No.45895618[source]▶

>>45894805 (TP) #

The vulnerability in question is being severely underestimated. There are many other comments in this thread going into detail. UAF = RCE.

replies(1): >>45896043 #

7. kragen ◴[12 Nov 25 03:17 UTC] No.45896043[source]▶

>>45895618 #

Use-after-free bugs (such as the vulnerability in question, https://issuetracker.google.com/issues/440183164) usually can be exploited to result in remote code execution, but not always. It wouldn't be prudent to bet that this case is one of the exceptions, of course.

8. ikiris ◴[12 Nov 25 05:01 UTC] No.45896537[source]▶

>>45895089 #

Maintainers rarely understand or agree with the severity of a bug until an exploit beats them over the head publicly in a way they are unable to sweep under the rug.

replies(2): >>45896705 #>>45899007 #

9. woodruffw ◴[12 Nov 25 05:36 UTC] No.45896705{3}[source]▶

>>45896537 #

Yes, I think a defining aspect of vulnerability disclosure is how perverted the incentives structure is for all parties, including maintainers.

10. CGamesPlay ◴[12 Nov 25 07:08 UTC] No.45897183[source]▶

>>45894805 (TP) #

That quote felt pretty disingenuous. OK, so the proof of concept was found in some minor asset of an old video game. But is it an exploitable vulnerability? If so, you will quickly find it on modern-day scummy advertising networks. Will it still be "medium severity"? Not clear either way to me, from the quote.

11. walletdrainer ◴[12 Nov 25 09:46 UTC] No.45898234[source]▶

>>45894919 #

This bug can most likely lead to RCE, proving that it can’t is generally a very difficult problem.

There’s absolutely no reason to assume that it does not lead to RCE, and certainly no reason whatsoever to invest significant time to prove that one way or the other unless you make a living selling exploits.

12. Orygin ◴[12 Nov 25 11:49 UTC] No.45899007{3}[source]▶

>>45896537 #

On the other hand, reporters giving a CVE a 10 for a bug in an obscure configuration option that is disabled by default in most deployments is bit over the top. I've seen security issues being reported as world ending, being there for years, without anyone being able to make an exploit PoC.

↑