Most active commenters
  • Brian_K_White(5)

←back to thread

FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)
1125 points CrankyBear | 20 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 #
AbrahamParangi ◴[11 Nov 25 19:50 UTC] No.45891930[source]▶
If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.
replies(6): >>45892251 #>>45893043 #>>45893172 #>>45896030 #>>45899685 #>>45900110 #
1. eddd-ddde ◴[11 Nov 25 20:16 UTC] No.45892251[source]▶
So your claim is that buggy software is better than documented buggy software?
replies(2): >>45892307 #>>45893385 #
2. rsanek ◴[11 Nov 25 20:20 UTC] No.45892307[source]▶
I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.
replies(2): >>45892337 #>>45899330 #
3. jakeydus ◴[11 Nov 25 20:23 UTC] No.45892337[source]▶
Yeah it's more effort, but I'd argue that security through obscurity is a super naive approach. I'm not on Google's side here, but so much infrastructure is "secured" by gatekeeping knowledge.
replies(2): >>45893192 #>>45895865 #
4. Brian_K_White ◴[11 Nov 25 21:33 UTC] No.45893192{3}[source]▶
I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another.

"obscurity isn't security" is true enough, as far as it goes, but is just not that far.

And "put the bugs that won't be fixed soon on a billboard" is worse.

The super naive approach is ignoring that and thinking that "fix the bugs" is a thing that exists.

replies(2): >>45893826 #>>45894886 #
5. user3939382 ◴[11 Nov 25 21:51 UTC] No.45893385[source]▶
it’s not a claim it’s common sense that’s why we have notice periods
6. rcxdude ◴[11 Nov 25 22:34 UTC] No.45893826{4}[source]▶
If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.
replies(2): >>45894301 #>>45900124 #
7. Brian_K_White ◴[11 Nov 25 23:24 UTC] No.45894301{5}[source]▶
More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place.

Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have the option not to use the surface service or app let alone control it's subcomponents.

replies(2): >>45894767 #>>45895822 #
8. dotancohen ◴[12 Nov 25 00:19 UTC] No.45894767{6}[source]▶
The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.
replies(1): >>45896740 #
9. tptacek ◴[12 Nov 25 00:33 UTC] No.45894886{4}[source]▶
The bug exists whether it's reported to the maintainers or not, so yeah, it's pretty naive.
replies(1): >>45903590 #
10. rcxdude ◴[12 Nov 25 02:40 UTC] No.45895822{6}[source]▶
It's a heck of a lot better than being unaware of it.

(To put this in context: I assume that on average a published security vulnerability is known about to at least some malicious actors before it's published. If it's published, it's me finding out about it, not the bad actors suddenly getting a new tool)

replies(1): >>45897427 #
11. strken ◴[12 Nov 25 02:46 UTC] No.45895865{3}[source]▶
Given that Google is both the company generating the bug reports and one of the companies using the buggy library, while most of the ffmpeg maintainers presumably aren't using their libraries to run companies with a $3.52 trillion dollar market cap, would you argue that going public with vulnerabilities that affect your own product before you've fixed them is also a naive approach?
replies(1): >>45896769 #
12. Brian_K_White ◴[12 Nov 25 05:46 UTC] No.45896740{7}[source]▶
There is no "the bug". The discussion is about what to do with the power of bug-finding tools.
replies(1): >>45900497 #
13. zamadatix ◴[12 Nov 25 05:51 UTC] No.45896769{4}[source]▶
Sorry, but this states a lot of assumption as fact to ask a question which only makes sense if it's all true. I feel Google should assist the project more financially given how much they use it, but I don't think Google shipping products using every codec they find bugs for with their open source fuzzer project is a reasonable guess. I certainly doubt YouTube/Chrome let's you upload/compiles ffmpeg with this LucasArts format, as an example. For security issues relevant to their usage via Chrome CVEs etc, they seem to contribute on fixes as needed. E.g. here is one via fuzzing or a codec they use and work on internally https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb...

In regards whether it's a bad idea to publicly document security concerns found regardless whether you plan on fixing them, it often depends if you ask the product manager what they want for their product or what the security concerned folks in general want for every product :).

14. Brian_K_White ◴[12 Nov 25 07:51 UTC] No.45897427{7}[source]▶
it's only better if you can act on it equal to the bad guys. If the bad guys get to act on it before you, or before some other good guys do on your behalf, then no it's not better

remember we're not talking about keeping a bug secret, we're talking about using a power tool to generate a fire hose of bugs and only doing that, not fixing them

15. bawolff ◴[12 Nov 25 12:29 UTC] No.45899330[source]▶
> I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.

That just means the script kiddies will have more trouble, while more scary actors like foreign intellegence agencies will have free reign.

replies(1): >>45903945 #
16. eptcyka ◴[12 Nov 25 13:48 UTC] No.45900124{5}[source]▶
Which codec is it?
replies(1): >>45904843 #
17. zamadatix ◴[12 Nov 25 14:18 UTC] No.45900497{8}[source]▶
"The bug" in question refers to the one found by the bug-finding tool the article claims triggered the latest episode of debate. Nobody is claiming it's the only bug, just that this triggering bug highlighted was a clear example of where there is actually such a clear cut line.

Google does contribute some patches for codecs they actually consume e.g. https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb..., the bug in question was just an example of one the bug finding tool found that they didn't consume - which leads to this conversation.

18. Brian_K_White ◴[12 Nov 25 18:12 UTC] No.45903590{5}[source]▶
You observe that it is better to be informed than ignorant.

This is true. Congratulations. Man we are all so smart for getting that right. How could anyone get something so obvious and simple wrong?

What you leave out is "in a vacuum" and "all else being equal".

We are not in a vacuum and all else is not equal, and there are more than those 2 factors alone that interact.

19. HDThoreaun ◴[12 Nov 25 18:32 UTC] No.45903945{3}[source]▶
Foreign intelligence has free rein either way. The script kiddies are the only ones that can be stopped by technological solutions.
20. Scion9066 ◴[12 Nov 25 19:20 UTC] No.45904843{6}[source]▶
I believe it's: sanm LucasArts SANM/SMUSH video