4 ms·
Sure but how. Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what? We are talking about software commonly for end users
by cogman10 1y ago
Sure but how.
Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what?
We are talking about software commonly for end users deployed to encode their own media. Something that rarely comes in untrusted forms. For an exploit to happen, you need to have a situation where an attacker gets out a exploited media file which people commonly transcode via FFMPEG. Not an easy task.
This sure does matter to the likes of google assuming they are using ffmpeg for their backend processing. It doesn't matter at all for just about anyone else.
You might as well tell me that `tar` has a CVE. That's great, but I don't generally go around tarring or untarring files I don't trust.
- omnicognate 1y agoAIUI, (lib)ffmpeg is used by practically everything that does anything with video, including such definitely-security-sensitive things as Chrome, which people use to play untrusted content all the time.
- cogman10 1y agohmm, didn't realize chrome was using ffmpeg in the background. That definitely makes it more dangerous than I supposed. Looks like firefox does the same.
- conradev 1y agoFirefox has moved some parsers to Rust: https://github.com/mozilla/mp4parse-rust https://github.com/mozilla/mp4parse-rust
- rebelwebmaster 1y agoFirefox also does a lot of media decoding in a separate process.
- xxs 1y agoPretty much anything that has any video uses the library (incl. youtube)
- godshatter 1y agoThen maybe the Google chrome devs should submit a PR to ffmpeg.
- omnicognate 1y agoSure. And fund them.
- walletdrainer 1y agoChrome devs frequently do just that, Chrome just doesn’t enable this codec.
- manquer 1y agoFfmpeg is a versatile toolkit used in lot of different places. I would be shocked if any company working with user generated video from the likes of zoom or TikTok or YouTube to small apps all over which do not have it in their pipeline somewhere.
- deaddodo 1y agoThere are alternatives such as gstreamer and proprietary options. I can’t give names, but can confirm at least two moderately sized startups that use gstreamer in their media pipeline instead of ffmpeg (and no, they don’t use gst-libav). One because they are a rust shop and gstreamer is slightly better supported in that realm (due to an official binding), the other because they do complex transformations with the source streams at a basal level vs high-level batch transformations/transcoding.
- manquer 1y agoThere are certainly features and use cases where gstreamer is better fit than ffmpeg. My point was it would be hard to imagine eschewing ffmpeg completely, not that there is no value for other tools and ffmpeg is better at everything. It is so versatile and ubiquitous it is hard to not use it somewhere. In my experience there usually is always some scenarios in the stack where throwing in ffmpeg for a step is simpler and easier even if there no proper language binding etc, for some non-core step or other. From a security context that wouldn't matter, As long it touches data, security vulnerabilities would be a concern. It would be surprising, not that it would impossible to forgo ffmpeg completely. It would be just like this site is written Lisp, not something you would typically expect not impossible.
- deaddodo 1y agoI wasn’t countering your point, I just wanted to add that there are alternatives (well, an alternative in the OSS sphere) that are viable and well used outside of ffmpeg despite its ubiquity.
- adastra22 1y agoUpload a video to YouTube or Vimeo. They almost certainly run it through ffmpeg.
- conradev 1y agoffmpeg is also megabytes of parsing code, whereas tar is barely a parser. It would be surprising to find memory corruption in tar in 2025, but not in ffmpeg.