←back to thread

FFmpeg dealing with a security researcher

(twitter.com)
104 points trollied | 1 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 #
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. vreg ◴[01 Nov 25 22:24 UTC] No.45785977[source]▶
If that is true then Google should be strictly sandboxing ffmpeg and filtering the input before it even gets there. A solid defense-in-depth approach would make sure it's highly unlikely this vulnerable code would be reached, and if it was, there would be effectively no impact.

They should be building ffmpeg with a minimal feature set anyway, so none of these obscure codecs end up included in the final binary.