Hacker News Reader

Comment by cm2187 | Hacker News Reader

Though there is one part I didn’t understand in that interview. They were complaining of being overwhelmed by AI submitted bug reports (fair), including for obscure codecs that must have been used by a couple of users at most. And therefore implying that securing those codecs is low priority/important.

I don’t understand that. To me the severity has nothing to do with how popular is a code path, but whether that code path is accessible to an attacker. If I upload a specially crafted .mkv with a little known codec on YouTube and they use ffmpeg to process it, and I compromise YouTube’s infrastructure that way, it’s a pretty big deal, no matter the popularity of that codec.

View on HN

That sounds nice in theory, but it seems obvious to me there is a major discrepancy between who is burdened with this responsibility, and who benefits from the result. Given many of these contributors are unpaid volunteers, maybe the infrastructure provider needs to secure FFmpeg in another way, for example by restricting codecs or by running it in a container?

The creator of borg and k8s of course already run such tools for untrusted inputs in containers, but there is also an endless stream of container escapes.

AppArmor profile is probably what you are looking for to run ffmpeg on untrusted input

They claimed that this was not a problem since the codec was so uncommon, but without doing steps like removing it from the main tree or making it not built by default in major distros.

I understand that from the perspective of "how many people will this crash for", but from a security perspective it is nonsensical. Even if it is an uncommon codec if the authors decide to keep the codepath there by default it is exploitable in most installs.

I love ffmpeg but that whole episode left a bit of a bad taste.

> To me the severity has nothing to do with how popular is a code path, but whether that code path is accessible to an attacker.

That's true for targeted attacks. For untargeted attacks, attackers have little incentive to do the exploit.

Targeted to what? ffmpeg? Ffmpeg is the OpenSSL of video transcoding, it is used absolutely everywhere. If there is a vulnerability in ffmpeg, any website that processes user supplied videos is vulnerable

It's all about time in the day, my friend. Do you want to secure a feature used by 100% of your users or 0.01% of your users? Which has a better ROI?

Given that it is easy to feed FFMPEG arbitrary input to exploit any vulnerability, popular codecs are very likely to be already secure enough, while unpopular ones are far more dangerous and deserve more attention. It can be assumed that an attacker would target the worst, easiest to exploit codec they can find in the whole of FFMPEG.

It's used by most users, that's what they are saying, it doesn't matter that the file format is obscure.

If you make a video player based on ffmpeg you take input videos. The attacker can share a specially crafted video with the victim. Same kind of attack as sharing word documents.

when it comes to security popularity doesn't matter all that much. If something is not used and insecure then the decision should be to drop the feature, not to ignore the security issue.

If Big Deployment is using a stock ffmpeg build rather than one that actually enables only the things they actually use, I feel like that's on Big Deployment.

But the point of ffmpeg is that it can consume pretty much any format. If you let end users upload videos, that is exactly what you need, it’s not desirable to have a very restrictive list of formats you will accept.

Not having massive exposed and untested surface area is very much desireable. Every platform has a highly restrictive list of formats and containers for this exact reason.

Reply on news.ycombinator.com