Most active commenters
  • walletdrainer(3)

←back to thread

FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)
1125 points CrankyBear | 11 comments | 11 Nov 25 18:32 UTC | HN request time: 0.022s | source | bottom
Show context
phkahler ◴[11 Nov 25 19:41 UTC] No.45891830[source]▶
From TFA this was telling:

Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ”

I agree with the headline here. If Google can pay someone to find bugs, they can pay someone to fix them. How many time have managers said "Don't come to me with problems, come with solutions"

replies(8): >>45891966 #>>45891973 #>>45893060 #>>45893320 #>>45896629 #>>45898338 #>>45902990 #>>45906281 #
dvfjsdhgfv ◴[11 Nov 25 21:22 UTC] No.45893060[source]▶
> "Don't come to me with problems, come with solutions"

The problem is, the issue in the article is explicitly named as "CVE slop", so if the patch is of the same quality, it might require quite some work anyway.

replies(1): >>45893094 #
jeffbee ◴[11 Nov 25 21:25 UTC] No.45893094[source]▶
The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1
replies(1): >>45893528 #
michaelt ◴[11 Nov 25 22:05 UTC] No.45893528[source]▶
It's a good quality bug report.

But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1]

Pretty crazy that ffmpeg supports the codec in the first place, IMHO.

I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't been used since the Clinton administration. gstreamer divides their plugins into 'good', 'bad' and 'ugly' to give them somewhere to stash unmaintained codecs.

[1] https://web.archive.org/web/20250419105551/https://wiki.mult...

replies(5): >>45893611 #>>45893616 #>>45895592 #>>45895955 #>>45896300 #
jsnell ◴[11 Nov 25 22:14 UTC] No.45893611[source]▶
It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable.

The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as the common ones.

> Pretty crazy that ffmpeg supports the codec in the first place, IMHO.

Yes.

replies(3): >>45894446 #>>45894851 #>>45895412 #
bigstrat2003 ◴[12 Nov 25 00:28 UTC] No.45894851[source]▶
Sure, it's a valid bug report. But I don't understand why there has been so much drama over this when all the ffmpeg folks have to do is say "sorry, this isn't a priority for us so we'll get to it as soon as we can" and put the issue in the backlog as a low priority. If Google wants the issue fixed faster, they can submit a fix. If they don't care enough to do that, they can wait. No big deal either way. Instead, ffmpeg is getting into a public tiff with them over what seems to be a very easily handled issue.
replies(2): >>45895522 #>>45895584 #
1. iscoelho ◴[12 Nov 25 01:57 UTC] No.45895522[source]▶
FFMPEG is upset because Google made the exploit public. They preferred that it remained a zero-day until they decided it was a priority.

I don't understand how anyone believes that behavior is acceptable.

replies(2): >>45895849 #>>45896321 #
2. fulafel ◴[12 Nov 25 02:43 UTC] No.45895849[source]▶
There's no exploit on the bug report at least, unless you consider the crash reproducer one.
replies(1): >>45895984 #
3. iscoelho ◴[12 Nov 25 03:04 UTC] No.45895984[source]▶
UAF bugs lead to RCE exploit chains.
replies(1): >>45896738 #
4. bigiain ◴[12 Nov 25 04:15 UTC] No.45896321[source]▶
That behaviour is indeed totally unacceptable. At your job. Where they're paying you, and especially if they're paying you at FAANG type pay scales.

If you're an unpaid volunteer? Yeah - nah. They can tell you "Sorry, I'm playing with my cat for the next 3 months, maybe I'll get to it after that?", or just "Fuck off, I don't care."

(I'm now playing out a revenge fantasy in my head where the ffmpeg team does nothing, and Facebook or Palantir or someone similar get _deeply_ hacked via the exploit Google published and theat starts the planets biggest ever pointless lawyers-chasing-the-deepest-pockets fight.)

replies(1): >>45898014 #
5. fulafel ◴[12 Nov 25 05:45 UTC] No.45896738{3}[source]▶
They can if someone manages to develop an exploit. Let's not confuse vulnerabilities and exploits.
replies(1): >>45898277 #
6. walletdrainer ◴[12 Nov 25 09:12 UTC] No.45898014[source]▶
Or perhaps you’re a FAANG security researcher and your time will be better spent serving the OSS community as a whole by submitting as many useful bug reports as possible, instead of slightly fewer reports with patches included.

In this particular case it’s hardly obvious which patch you should submit. You could fix this particular bug (and leave in place the horrible clunky codec that nobody ever uses) OR you could just submit a patch that puts it behind a compile flag. This is really a decision for the maintainers, and submitting the latter (much better!) patch would not save the maintainers any meaningful amount of time anyway.

replies(1): >>45901594 #
7. codedokode ◴[12 Nov 25 09:53 UTC] No.45898277{4}[source]▶
This bug might lead to vulnerability and that's enough. It makes no sense to waste lot of time and research whether it is possible or not - it is faster to remove the buggy codec nobody needs or make a fix.
8. Wowfunhappy ◴[12 Nov 25 15:47 UTC] No.45901594{3}[source]▶
I don’t understand how it helps the community to publicly release instructions for attacking people, unless you’re trying to incentivize a company to fix their crap. In this case, there is no company to incentivize, so just report it privately.

You can say publicly that “there is an ABC class vulnerability in XYZ component” so that users are aware of the risk.

replies(1): >>45902125 #
9. walletdrainer ◴[12 Nov 25 16:29 UTC] No.45902125{4}[source]▶
It’s OSS so somebody who cares will fix it, and if nobody cares then it doesn’t really matter.

This also informs users that it’s not safe to use ffmpeg or software derived from it to open untrusted files, and perhaps most importantly releasing this tells the distro package maintainers to disable the particular codec when packaging.

replies(1): >>45904123 #
10. Wowfunhappy ◴[12 Nov 25 18:44 UTC] No.45904123{5}[source]▶
Right, I just don’t see why they need to publish the actual exploit.
replies(1): >>45906665 #
11. walletdrainer ◴[12 Nov 25 21:05 UTC] No.45906665{6}[source]▶
They have not, neither have they indicated that they’re planning to do so.