[jstanley]

Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up.

They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used.

I was left wondering whether they were oblivious to the fact that an attacker who can supply a video file to you is free to use whatever video codec they want? It wouldn't matter if the developers thought the codec was never used at all; if it is still available then an attacker can use it.

Or was I just missing something? Is there a good reason why vulnerabilities in this codec are not a big deal after all?

[m4rtink]

Is it really available in practice ? Eg. do major distros even compile ffmpeg with these obscure codecs or you need to recompile it yourself to get it ?

[TD-Linux]

Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.

[franga2000]

The user is not free to use whatever codec they want. Many niche codecs can't be put into the usual containers, so if you only accept QuickTime/MP4 and AVI, sometimes even just by limiting the file extension, those codecs can't be used.

If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up. It would be nice if you could do that, but that's not a guarantee ffmpeg has ever provided, nor would it make sense for them to spend their limited resources on it.

[RetroTechie]

> If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up.

Isn't that what fuzzing and input validation is about? Most bugs presented in article suggest failures in the latter.

[defrost]

Big pipeline fat data users of ffmpeg can and do build their own executables that only include the top N codecs, that eliminates minor bug in obscure never used format problems pretty thoroughly.

[twobitshifter]

I’m this video you will also learn that much of it is coded in assembly! The developers are prioritizing performance to the extreme, which has its benefits, but I would expect assembly to open up the code to a whole world of vulnerabilities.