←back to thread

104 points trollied | 2 comments | | HN request time: 0s | source
Show context
vqtska ◴[] No.45785720[source]
I wonder if this vulnerable codec is enabled by default when building FFmpeg? Because if so, then it doesn't matter that it's a "1990s game codec" because any application using FFmpeg to accept arbitrary video files is vulnerable to memory corruption, which should probably be taken more seriously.
replies(4): >>45785760 #>>45785825 #>>45786027 #>>45786093 #
chemotaxis ◴[] No.45785760[source]
The somewhat depressing reality is that if you're running ffmpeg on user-supplied multimedia without putting it in a bulletproof sandbox, you're just bound to have a bad time.

Video decoding is one of these things that no one seems to know how to do safely in C or C++, not in the long haul. And that's probably fine, because we have lightweight sandboxing tech that makes this largely moot - but there's an extra step you need to take. Maybe it's on the ffmpeg project that they don't steer people in that direction.

Trying to fix these bugs piecemeal is somewhat pointless - or at least, we've been trying for several decades, throwing a ton of manpower and compute at it, and we're still nowhere near a point where you could say "this is safe".

replies(1): >>45789344 #
1. ozgrakkurt ◴[] No.45789344[source]
Does this mean we have to run vlc in a sandbox while watching a downloaded film?
replies(1): >>45789971 #
2. awakeasleep ◴[] No.45789971[source]
In production? With a user-supplied film?

You seem to be captured by the “all or nothing” security fallacy, when security must be viewed through the lens of (probability) x (impact)