←back to thread

FFmpeg dealing with a security researcher

(twitter.com)
104 points trollied | 3 comments | 01 Nov 25 20:59 UTC | HN request time: 0.628s | 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 #
lukeschlather ◴[01 Nov 25 21:57 UTC] No.45785787[source]▶
Google operates a transcoder API which I suspect is just ffmpeg under the hood, and if you assume that they accept any input file, they really can't afford for decoders to have security vulnerabilities. Of course, then Google should be coming with more resources and not just filing bugs because it's Google that has the unusual use case.
replies(3): >>45785977 #>>45786069 #>>45786153 #
1. tkfoss ◴[01 Nov 25 22:38 UTC] No.45786069[source]▶
Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?
replies(1): >>45788090 #
2. yegle ◴[02 Nov 25 05:48 UTC] No.45788090[source]▶
Please stop spreading this misinformation. At least in Debian this is enabled by default (and as another post indicates, Ubuntu as well).

Run the following command to confirm:

ffmpeg -codecs|grep sanm

replies(1): >>45795901 #
3. astrange ◴[03 Nov 25 04:31 UTC] No.45795901[source]▶
If you're using ffmpeg it's recommended to just enable the things you need, or only accept some container formats. But yes, in a generic package everything is enabled.