←back to thread

FFmpeg dealing with a security researcher

(twitter.com)
104 points trollied | 2 comments | 01 Nov 25 20:59 UTC | HN request time: 0s | source
Show context
TheChaplain ◴[01 Nov 25 21:42 UTC] No.45785676[source]▶
The comments from the public.. Just wow we are doomed..

To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files (Lucasfilm Smush). Devs are not happy they get timewasting reports on stuff that rarely anyone ever uses except an exceptionally tiny group.

Then people start berating them without even knowing the full story...

replies(3): >>45785704 #>>45785787 #>>45786348 #
haskellshill ◴[01 Nov 25 23:11 UTC] No.45786348[source]▶
>rarely anyone ever uses

It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

replies(1): >>45786470 #
defrost ◴[01 Nov 25 23:31 UTC] No.45786470[source]▶
If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs.

In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.

replies(2): >>45786561 #>>45789812 #
1. Ukv ◴[01 Nov 25 23:45 UTC] No.45786561[source]▶
To my understanding this bug would affect anyone using ffmpeg on untrusted input. Google may already be limiting to certain codecs in their own use, but should still report the issue (as they have here).
replies(1): >>45787710 #
2. GaryBluto ◴[02 Nov 25 03:41 UTC] No.45787710[source]▶
Yeah but who cares about them, right? It's a volunteer project don't you know.