←back to thread

1125 points CrankyBear | 4 comments | | HN request time: 1.191s | source
Show context
phkahler ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 #
iscoelho ◴[] 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 #
1. fulafel ◴[] No.45895849[source]
There's no exploit on the bug report at least, unless you consider the crash reproducer one.
replies(1): >>45895984 #
2. iscoelho ◴[] No.45895984[source]
UAF bugs lead to RCE exploit chains.
replies(1): >>45896738 #
3. fulafel ◴[] No.45896738[source]
They can if someone manages to develop an exploit. Let's not confuse vulnerabilities and exploits.
replies(1): >>45898277 #
4. codedokode ◴[] No.45898277{3}[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.