←back to thread

FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)
1125 points CrankyBear | 7 comments | 11 Nov 25 18:32 UTC | HN request time: 0.001s | source | bottom
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. Yokolos ◴[11 Nov 25 21:13 UTC] No.45892941[source]▶
I see you didn't read the article.

The problem isn't Google reporting vulnerabilities. It's Google using AI to find obscure bugs that affect 2 people on the planet, then making a CVE out of it, without putting any effort into fixing it themselves or funding the project. What are the ffmpeg maintainers supposed to do about this? It's a complete waste of everybody's time.

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

replies(4): >>45893950 #>>45895884 #>>45898422 #>>45899437 #
2. inkysigma ◴[11 Nov 25 22:47 UTC] No.45893950[source]▶
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.
replies(1): >>45899451 #
3. saagarjha ◴[12 Nov 25 02:49 UTC] No.45895884[source]▶
Close the bug, if they don’t care. They don’t want to do that because then people will yell at them for not caring.
4. Dylan16807 ◴[12 Nov 25 10:14 UTC] No.45898422[source]▶
> that affect 2 people on the planet

Wrong. The original files only affect 2 people. A malicious file could be anywhere.

Do you remember when certain sequences of letters could crash iphones? The solution was not "only two people are likely to ever type that, minimum priority". Because people started spreading it on purpose.

5. seb1204 ◴[12 Nov 25 12:40 UTC] No.45899437[source]▶
Mark it low, and estimate by when it can be fixed (3, 4 months from now). Advise google of it. Google does not need to disclose this bug that fast. If I do something one the side or as hobby and big corp comes by to tell me to hurry up I feel inclined to say no thanks.
6. seb1204 ◴[12 Nov 25 12:42 UTC] No.45899451[source]▶
Why does google simply build their own ffmpeg from source without the codec?
replies(1): >>45901506 #
7. woodruffw ◴[12 Nov 25 15:40 UTC] No.45901506{3}[source]▶
They almost certainly do. But it's also in the public interest to responsibly disclose vulnerabilities in components that don't directly affect you.