Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago:
So, while it's a demo of the capabilities of LLMs, this should not be at all surprising. Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. I know that people do, and these people are taking unreasonable risks.
FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.
On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through.
Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.
If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.
Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no?
I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.
You could assume that if someone has the technical level to identify a vulnerability and how to exploit it, they probably have the technical level to fix it.
In most cases researchers have no interest in actually "making the software better" and publishing vulns is just a way to increase their cred to land a better job.
FFMPEG's position as a well know very popular open source project means it's very interesting for this type of researcher to find a vuln and put their name on it.
If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake.
In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with those complex decoders operating on data which is often untrusted. I wouldn’t suggest a project of that scale lightly but it’s at least a near-perfect fit on the problem domain.
I would say it’s the opposite. coreutils is core utils, you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. They are also relatively simple.
With ffmpeg, anyone who knows anything about secure application development in the past 20 years knows that it is a huge security tarpit and throwing it untrusted inputs in trusted environment is asking to be owned. You thoroughly sandbox that shit. That’s true for all untrusted media conversion, but absolutely with ffmpeg.
My point about coreutils was that they’re rarely used in situations where an attacker can provide arbitrary input - it’s more like race conditions with code already running on the same system trying to escalate access – so what you need to protect against are things like race conditions around file operations or symlink safety.
The coreutils rewrite was shit because of the license change. Most of the other founding ideas were also bad as you say, but the license change was absolutely a much worse signal. Just a bunch of people rolling over and showing big corps their belly. And for what? So they can be more exploited by people that treat them like cattle.
Look, I like Rust and ported every bit of C I used to it a decade ago but this is not a compelling argument. The coreutils rewrite is an existence proof that the typing system doesn’t motivate this class of error and a moment’s thought would explain why (you’d have to be very familiar with the attack patterns to know to create types like “handle to private file failing if the name exists” and they weren’t).
What could help would be a modern API implementing the same patterns that GNU coreutils evolved over the last 4 decades but that’d be less the language than the library and it’d only go so far because some of those utilities legitimately need to things which are otherwise rare in most applications.
To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.
I personally like to use C and find Rust annoyingly complex. I think it may be an alternative to C++, but C++ is also too complex for my taste. I do not find it annoying to free several allocated structures when there is an error, but one could also automate this with a often used extension.
There is also the question whether trading memory safety against supply chain risks is really worth it.
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?
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 ?
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.
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.
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.
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.
Until the people going on about making an equivalent in pure rust being automatically much safer, stop talking about it and actually get on with making it, of course!
FFmpeg is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain.
It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.
while sandboxing ffmpeg directly isn't difficult, unfortunately with something like MPV/VLC that uses ffmpeg it's more challenging. until recently (virtio gpu native context) it wasn't even possible to sandbox a video player without losing all hardware acceleration. at least not from the outside, they could always try to sequester ffmpeg and seccomp it to hell like chromium.
Sandboxing not only OS access but also hardware access feels almost impossible to be honest. At least not via user-friendly exec based stuff like bwrap.
I wouldn't call "nice find, care to help us fix that?" extremely hostile. It can be frustrating for open source projects that far more people want a pat on the back for the identification of a problem (be it security, performance, documentation, or anything else) than there are people who have the time and inclination to help resolve the issue (or ability and inclination to fund the project so it can more easily find help if needed). The use of LLM based tools apparently making that pat on the back easier to attain is going to exacerbate that problem for a while at least.
I don’t deal with ffmpeg or C/asm, but there are certainly some 4gl applications that a random patch may cause more problems than it solves. I imagine many researchers would be in that box.
There's certainly assembly that maps directly to the machine language bytes, I assume you are talking about the version of assembly with the high level loop macros
Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.
Back in 2004 when free email services like hotmail were limited to 10-15mb, on April 1st the evening standard front page headline, which I saw in the office around 2pm, was something “Google lunched 1gb email”
I couldn’t believe they had fallen for an April fools so hard.
I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.
I've run a bug bounty program for a relatively large corporation and you are exactly right. It's worse in open source, because none of the developers owe a researcher their time. At least in a bug bounty program you've communicated willingness both ways already
One dude running an X account is not indicative of a community to be honest.
That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.
If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.
If there was a nearly inexhaustible supply of Indian security researchers emailing you a nearly inexhaustible supply of LLM slop daily, there is a point where you or I would stop caring too.
ffmpeg is Free Software. You are also free not to use it.
Oddly enough, despite all these endless grievances, no one has come up with a better or more capable tool, certainly not one that is freely available.
Evidently no one cares either, because most implementations of ffmpeg I've seen typically run it as root "because we have to". Don't worry we use Docker bro.
> AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.
Ok but who is going to sift through it all to triage the good bits when you're working on something for free?
> Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation
Who gives a shit about reputation when you're the only game in town?
There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.
Its not as full featured as ffmpeg but I remember hearing about mediabunny, It's a web native ffmpeg alternative, and according to its website, seems to be a lot faster than ffmpeg.wasm
> Ok but who is going to sift through it all to triage the good bits when you're working on something for free?
Its like anything else in open source. Maintainers will do so if they care. Maybe they decide they don't care. That is always their decision to make but there are consequences for the project. Maybe those consequences make sense. Being a maintainer is all about making cost-benefit trade offs.
> Who gives a shit about reputation when you're the only game in town?
Its up to the maintainers whether they care or not. It depends on what they value.
Ultimately if maintainers make decisions that are at odds with what their userbase want, someone eventually forks and people vote with their feet.
Today it's an industry driven by unscrupulous clout-chasers and a commitment to quantity over quality.
There is a difference between going through patches and pull requests vs. the endless stream of LLM-assisted bullshit that has started cluttering security inboxes in the last few years.
There is a difference between a proper vulnerability researcher and a clout chaser calling themselves a vulnerability researcher. Research for a start, to assess the problem to see if it is genuine and if so if there are significant mitigating factors (by default or that can be implemented), and checking if it hasn't already been reported, instead of just copypasting some LLM output with minimal review. And to many clout chasers everything they find is a grade A world wrecking highest possible priority "if you don't drop everything else and fix this now you are a kitten murderer and I'm going to release the information to the world in 24 hours" level issue (they know this because they suggested it to an LLM and it told them they were so right).
No there isn't. The vulnerability is either real or it isn't. How you feel about the researchers doesn't enter into it. People angry about vulnerability research have been making this argument since 1992.
this, exactly: sometimes the vulnerability isn't, or isn't a fraction as serious as it is made out to be because it doesn't affect any sane configuration. And the project contributors don't know this until they've wasted time looking into it, time that could be spent looking into actual serious problems.
The extra problem right now is several people/groups dropping the same set of vulnerabilities with not coordination because they've got this great new tool to garner attention and want to be first. So projects have several things to look into that turn out to be exactly the same thing.
Plenty of people will loudly state that they are irresponsible for not looking into the reports that they send, so while that isn't a direct obligation it is certainly a punishment, via potential reputation damage¹, for not doing so.
--------
[1] for example, see comments elsewhere in this thread saying things like "maintainers will if they care"
Caring is only part of the problem. If you are inundated by low quality reports, or many duplicates of what turn out to effectively be the same problem, that you have to sift through to find the useful reports, then by the time you have something actionable you have no time left to take action on it.
The amount of reports coming in, particularly the low/zero quality ones, is apparently growing at a much faster rate than the time volunteers have for dealing with them.
Caring does not magically solve problems without enough people with enough time.
> Yes, and people will sit there and sip tea while waiting for "someone"? For how long?
Until someone cares enough to do it. This is open source software. When it comes to open source, the golden rule is you either do the things you care about yourself or stfu.
Given the libav fork wasn't all that long ago, it can obviously happen to ffmpeg just as much as it can happen to any other project.
Even before the advent of AI the quality of most reports was depressingly low. Most of your reports will quite simply come from folks in lower-wage countries that broadly don't speak English well and that use a shotgun approach to bug bounties. That means you are receiving a lot of them, they will be hard to read (assuming the information you need is in there at all) and if they get one success out of fifty then for them it is a really good return.
The advent of LLMs has made this a hundred times worse. Both because it makes it easier for most people to create reports that sound good (and so are more effort to dissect) and because people who didn't have to work hard to get any amount of competence are usually more entitled and more rude (the stakes are even lower for them).
It is economically no longer a good idea to run a bug bounty program at all. I honestly question whether or not even having a direct input for such things makes any sense anymore. The volume is becoming so great you need a classical spam filter to plow through it. But that won't work, because they all sound reasonable.
The majority of code in ffmpeg today isn't written by Fabrice, but also there's multiple axes that people view programming ability on. Some people can write software that will do things you couldn't imagine given the constraints. Some people can write software that is resilient against all malformed input. Sometimes these people are the same people, but frequently they're not.
Can't help laughing at a random ad hominem against John Carmack of all people, and about his opinion on a guy who is already widely regarded as an especially talented programmer.
I don't think that's fair. There's a lot of talent and grit behind ffmpeg. But for better or worse, getting the code to do what it's supposed to do requires a different mindset than getting it to not do anything else (i.e., to handle malicious inputs correctly).
The developers of ffmpeg are very good at the first thing and not very good at the second. But few people on this planet, if instructed to write a complex video format parser in C or assembly, can produce something that's secure on the first try. The main failing of the ffmpeg team is that they should have spent more time on architectural hardening and mitigations. Most other large projects of this type do.
My understanding is that ffmpeg is probably incredibly close to the metal, with tons of assembler mixed in. I imagine doing the same in Rust would include lots of `unsafe` blocks and a similar amount of assembly, so it wouldn't change much in terms of security. Or am I wrong?
Any multimedia project trying to support a large number of formats, whose usage in the wild differs by orders of magnitude, is going to have code of varying quality (although quality is not strictly correlated with usage: age and complexity are also big factors, among others). GStreamer puts plugins into different categories (-good, -bad, etc.) based on things like the maturity of the code, which helps you judge what risks you are taking. With FFmpeg it is harder to know which formats are more likely to have issues. Of course GStreamer can use FFmpeg, in which case you will also have all of FFmpeg's problems.
In both cases you are best off restricting things to what you actually use.
Gstreamer is a multimedia framework where the user creates media DAGs by placing video/audio/multimedia elements such as demuxers, decoders etc in a pipeline. The framework then takes care of running the media pipeline and handles the data buffering etc.
Within the framework there are multitudes of plugin packages that contain said elements and many of them are built on top of ffmpeg.
From what I understand gstreamer is more about building complex pipelines and plugins, ffmpeg is better at playing some obscure 20 year old video format extremely efficiently so you can watch it compiled for a potato.
That's not really true. Ffmpeg is a Swiss army knife for anything related to digital multimedia (old and new). It is broken into a few libraries but doesn't really have plugins.
Gstreamer has a different model, chaining together plugins. Lots of overlap, but I think Gstreamer only has real traction because some silicon vendors use it.
GStreamer doesn’t use ffmpeg’s pipeline at all. It implements a much more advanced directed graph with disconnect, connection and pad negotiation. You can dynamically swap out the entire filter graph during live playback with zero disruption. Swap feeds, outputs, effects… all at runtime.
ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines. You can use “switcher” components but the inputs are still static.
GStreamer is extremely special. The only thing that comes close was Microsoft’s DirectShow, which has since been replaced with Media Foundation which can’t do it. And while DirectShow did support it, it was fragile because many 3rd party filters did not support dynamic configuration.
GStreamer does use ffmpeg, but it just wraps the core encoder/decoder/filter code and discards the streams/graph/pipe part of ffmpeg.
It's also a command line tool, where you can design (limited) media graphs: sources, sinks, filters, encoders, decoders, muxers, demuxers. You don't express it as directly as gst-launch's pipeline syntax, but it's very much a pipeline.
GStreamer is not "just a different front end to ffmpeg". GStreamer is a pluggable media graph system.
"GStreamer" doesn't link against libav. The GStreamer plugin "gst-libav" links against libav. If you're not using the gst-libav, you're not using ffmpeg. I'd bet a relatively small amount of GStreamer use cases use gst-libav; I typically see people use e.g x264dec and x264enc (from the x264 plugin) to decode and encode media, or, for hardware encoding/decoding, the v4l2enc and v4l2dec elements (or elements from a SoC vendor's plug-in such as gst-rockchip). It also has its own non-libav elements to handle container formats, pixel format conversion, scaling, etc, which are more natural to use since they're part of the core gstreamer plug-in packages rather than gst-libav.
I completely agree, with regard for the GP's point about Android TV's with onboard ffmpeg libraries and Addon Apps that call on said libraries (or pull in their own) ..
Cheap arse low resource TVs should either include some form of sandboxing OR the entire device should be treated as a "can fall over" sandbox .. well isolated from any household LAN of consequence, etc.
It seems unlikely that BoxStore Brand Android TVs will be well designed with an eye to security so <shrug> they're an exercise for home net admin masochists and/or an opportunity to market sensible easy to use IoT age routers that come preconfigured to handle bad-device(s).
Am I getting this right, you expect TVs which are running Google TV (Android TV is the old name) to be less secure than TVs which are running a different operating system? I think the opposite is the case, because Google TV is developed by Google, which has a lot of experience with software security, while other TV operating systems are developed by companies which clearly don't have that experience.
Most of them require hardware acceleration from the CPU or GPU and that can potentially be exploited to escape the sandbox. GPUs in particular are difficult to sandbox.
The obvious question is, how many of those were the sort that writing in a memory-safe language would make impossible?
They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.
Rewriting ffmpeg in Rust will not solve it. The parts that are memory unsafe in ffmpeg, and similar projects, are not unsafe because C or C++ is inherently unsafe. Instead, it's the CODE that is unsafe. Translating the code (data structures, logic, etc) to Rust does not fix bugs in the code. That code will be littered with "unsafe" code, and of course, it will no longer be maintainable.
I think the industry is optimizing for the wrong thing. Generating thousands of AI-written bug reports is easy, at least with Mythos (preview 1) or GPT-5.5. Getting bugs fixed is the hard part.
A few months ago I started working on a system that finds critical security issues and opens PRs instead of just filing reports. The acceptance rate is sitting at roughly 94% so far. Most of the failures were due to project-specific kill switches or other internal mechanisms that weren’t documented, not because the vulnerability itself was misidentified.
Developers generally seem to prefer this approach. A bug report creates work. A good PR removes work. That sounds obvious, but a lot of security products still stop at the report and call it a day.
> I think the industry is optimizing for the wrong thing.
Indeed: The industry optimizes for speed, time to market, and features, and applies the ostrich model to everything that doesn't bring short-time revenue (security considerations, accessibility, vendor lock-in, interoperability, …)
This has been going on for as long as the industry exists, and now we start to have the proper tools to assess the damage and understand the brittleness of it all.
>The reach of this bug is what makes it serious. Any deployment that points FFmpeg at an attacker-influenced RTSP URL is exposed: media ingest pipelines fetching user-supplied stream URLs, surveillance and CCTV systems pulling RTSP feeds, and transcoding services processing remote AV1-over-RTP sources
Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can imagine this is exploitable today.
Some people might suggest it’s crucial to publish if you’re aware of a serious vulnerability, so that people using the software in a vulnerable way can take steps to mitigate the risk.
Speed and security are not good bedfellows. Combine that with really shitty standards and dozens of years of development...
Oh, and licensing. Licensing is the real killer. I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.
> I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.
I am confused.
> The MP3 format is now patent-free and requires no licensing fees to distribute or use. Fraunhofer IIS and Technicolor officially terminated their MP3 licensing programs, with all core patents having expired. Anyone can encode, decode, and distribute MP3 files or software without paying royalties.
Sorry I was painting a broad image. I'm also worried about copyright infringement, discovery, someone switching to a different different that requires glpl, etc
You raise a good point. You can substitute "MP3" with any patent-/copyright-/license-laden important media codec and you will face the same issues. Your comment would be very timely in the year 2005, when MP3 licensing was a serious issue for game devs.
I don’t think this is necessarily true! Constraints can be liberating: a language that allows strong encoding of invariants makes it easier for the language’s compiler to optimize.
I agree about long periods of development and difficult standards, though.
Even if this isn't as big a deal as this [advertisement for a security company] seems, it is a reminder that every application you release does have a security hole somewhere, and a script kiddie can now find it 5 minutes after release for $2 in credit. If you're not red-teaming your code before release, hackers are doing it after.
Inflated use of the term zero-day, while none of the described vulnerabilities is actually a zero-day. But it sounds and clicks good..
thank you for the PoC.
If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication.
When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.
Originally a zero-day exploit was one that was found by crackers on the first day of release of a software product. Like finding a licence crack for a new Microsoft program on the day it went on sale.
There used to be fierce competition to find such an exploit within those 24 hours, and great kudos for those who did.
Nowadays a zero-day can apparently be found years after release, which makes no sense.
Does "publication" refer to the software or to something documenting the existence of the bug? Because I thought zero-day meant the bug was exploited the same day the software containing the bug was released, but your phrasing sounds like if you exploit a bug before the maintainers know about it then it's a negative day.
I did so in the other reply thread of the comment you replied to.
> [Z]ero-day specifically compares when the white hats (vendors, system owners) and the black hats learn about the existence of a vulnerability. If white hats learn that a vulnerability exists by being subject to an in-the-wild black hat exploit of it, then it's a true zero-day.
And, again, you need to be aware that the vulnerability is the flaw or defect in the software or system (e.g., buffer overrun), and the exploit is the specific methodology that takes advantage of it (e.g., worm, malicious web request from a botnet, etc.).
Some people differentiate between a zero day vulnerability and a zero day exploit. I don't really find that is common anymore, and essentially everyone using it means zero-day exploit.
I understand why it's poorly understood. It's a snappy term, and people assume it means "bad" and nothing else because that's all you can get from the context. However, since most people also don't know the difference between a vulnerability and an exploit, they won't understand the definition of a zero-day when they read it.
But I'm still going to complain if a security vulnerability research company is using the term incorrectly in their own press copy. It makes them look amateurish.
No, that's the difference between exploit (knife) and either the incident or impact (wound). The vulnerability would be a gap in armor.
The vulnerability is the exposed weakness. Vulnerabilities get fixes, and they exist without anybody knowing about them. Vulnerabilities get CVEs assigned to them.
The exploit is the means of attack. It's the specific actions or calls that let you take advantage of a vulnerability. It could be a worm, or botnet scripts, or specifically crafted data[0]. A proof of concept is not an exploit itself, but it demonstrates that the vulnerability can be exploited.
An example of a vulnerability might be a gate where the gap between the door and the jam are too wide. The exploit is a coat hanger used to lift the inside latch from outside the gate. That results in unprivileged access.
And zero-day specifically compares when the white hats (vendors, system owners) and the black hats learn about the existence of a vulnerability. If white hats learn that a vulnerability exists by being subject to an in-the-wild black hat exploit of it, then it's a true zero-day.
> At this point the corrupted free pointer is called, and control of the instruction pointer is ours.
Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
The article glosses over this, but it looks like the next variable in the struct is conveniently the first parameter to the function, so you can run arbitrary code with system() or whatever. But, yeah, you would need some other exploit to defeat ASLR.
I've been using ffmpeg for a very long time, both personally and for services I've built. Fabrice Bellard is a genius, and the developers who have taken it so far have made the world measurably richer.
But I can't think of a program more worthy of sandboxing when run with untrusted input than ffmpeg. It's a huge amount of C dealing with the most complicated video and audio codecs, which is notoriously impossible to get completely right.
But it's not actually that big of a problem. I run ffmpeg inside a VM or gVisor, and the end result is usually a video file that I'm perfectly willing to play in my browser, where it gets decoded in yet another sandbox because this shit is hard.
What do you mean "video file that I'm perfectly willing to play in my browser". Isn't it safe to assume that no video file can escape the browser decoding sandbox?
I'm not up-to-speed with the current state of sandboxing in browsers, but in principle it's (on modern operating systems) not especially hard for them to sandbox the decoding into a separate process with basically no privileges beyond rendering a video stream. It's a bit trickier if we're only considering demuxing and delegating decoding to the hardware, but that's a much smaller attack surface.
A manually run ffmpeg on the command line does nothing to restrict its privileges, and its security model has very little interest in doing so, while browsers very much have.
The incentives structure is deeply broken in the field of Security Research.
They are the middle management of the FOSS world.
Celebrated for dumping more work on volunteers. The more urgent the work, the more they are celebrated. Acknowledging the realistic impact of issues or the pragmatic implications of an issue are at odds with their incentives.
It's hard not to see them as bottom feeders of the software industry and I wish we would starting treating them like pariah. Submit the PR or STFU.
Not suprised theres holes in codec implementations.
They are extremely complicated structurally.
Most modern codecs layer compression features endlessly in the pursuit of better compression.
The specs are insanely bloated.
Filesystems have the same problems, with huge bloated specs.
You wouldn't mount an untrusted filesystem.
Theres issues at all levels.
The filesystem, the stream muxer, the codec.
It would be nice if we could just use some simple uncompressed or lossless compression for video, and not need to have this mess of lossy codecs with endless compression features.
But computers/networks still dont have the bandwidth to practically handle uncompressed video in 2026, altho audio can be. I doubt theres many issues with lpcm.
Is the future of defense-against-foreign-agents-on-my-codebase to subtly hide prompt injections into one’s codebase that would defeat agents to find security bugs ?
If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
> DFVULN-123 (Integer Overflow): In the RTP LATM depacketizer (rtpdec_latm.c), latm_parse_packet() performs a signed 32-bit addition that overflows and bypasses its bounds check
Again there is another vulnerability caused by unchecked addition, and still modern languages like Rust or Go do not raise exception on overflow, and modern CPU architectures like RISC-V provide no overflow traps. And older languages like C or C++ do not have overflow checks also.
Ridiculous. It is obvious that humans cannot be trusted with writing correct arithmetics code.
Rust enables overflow checking in debug mode, you can (and I do) enable it in release mode as well.
Rust's default integer overflow in release mode is defined as well, it'll just wrap around. This makes it less likely to result in a vulnerability (unless you start writing unsafe Rust).
Additionally, integer overflow is less immediately dangerous in Rust, because buffer access is bounds-checked after the arithmetic. You can still get some logic bugs that eventually lead to vulnerabilities, but it's not an arbitrary memory write gadget.
What convinced me that this is wishful thinking was CVE-2023-53156. Yes, it used "unsafe" but the wraparound in release defeated the manual check, and when you aim for performance comparable to C, Rust tends to be full of unsafe blocks.
IMHO better C tooling would be a far better investment than rewriting in Rust.
Incremental/quantitative improvement isn't disproven by contradiction. Anecdote is not data. Look at a bigger dataset, e.g. https://github.com/rust-fuzz/trophy-case there's a ton of overflows that result in caught panics or OOMs, and not bypasses. It works to reduce defect rate and severity.
Note that C's tools for this like Valgrind, instrumented allocators and LLVM sanitizers work with Rust too. Investment in catching these in C generally helps unsafe Rust too, but Rust also has Miri, and a much better baseline for static analysis.
... do `unsafe {}` blocks not have the same semantics? I thought that was only about memory safety. Or are you thinking of cases where a wrapped-around integer gets interpreted as a pointer or something?
Zig raises overflow. There are +|= and +%= operators for clamped and wrapping addition.
Rust doesn't raise overflow by default. But you can just 123.checked_add(321). Now your code is unreadable, but it's overflow safe.
Honestly, based on the way I write code I'd rather something like an end of line comment. Like:
var x = y + z; # wrapped
Because I'm very unlikely to mix wrapped/checked/clamped arithmetic in a single line. It can't be a compiler state like doing(wrapped) { x + y } because in Zig every line must be "compilable" by itself, without requiring context from other parts of the code. Function names are too verbose. Casting is too verbose. Having a statement-level modifier would be a good compromise.
Agreed, the option that sacrifices security in search of performance should be the more verbose one. There's a reason Rust doesn't have `safe {}` blocks and there's a reason it chose immutable-by-default semantics.
Most of them involve very weird and unlikely scenarios and bad security practices or access to the ffmpeg binaries and being allowed to run arbitrary commands at an elevated permission.
In and of itself there's not a massive issue from what I can see, they're entry vectors that can lead to worse situations.
That's not to say they're not serious but if a Russian hacking group is using one of them it's in conjunction with other exploits or security flaws. Which is common in practice when it comes to decoding.
What about VLC's own built-in versions of decoding libraries (I think, from the FFmpeg project)? Is there a scenario here where we may have to deal with malicious MP4 files?
Help me understand: depthfirst seems to be bigging up their “security agent” here, but is it not just prompt engineering + writing skill files? What goes into producing a “security agent” beyond this? Feels like they’re really gussying up a process that is ultimately just LLM usage
For executables on Linux there are things like bubblewrap or firejail. One can also use a restrictive container. But those are strictly weaker than browser sandboxes.
The most secure way presently is to use qubes-os that allows to use a very hardened VM to run individual applications.
I just had an unsettling thought… those with access to Mythos/Fable finding these flaws — how many might be holding back and keeping some of these exploits in their back pocket?
I had to read your comment a couple of times to understand it. I assume you are saying that "/bin/ls" is the "most ordinary command imaginable"? I think your original quote is saying most ordinary when running ffmpeg, which has a famously complex command line interface.
Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago:
https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
So, while it's a demo of the capabilities of LLMs, this should not be at all surprising. Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. I know that people do, and these people are taking unreasonable risks.
FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.
On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through.
Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.
If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.
On the third hand, pestering and shaming open-source maintainers because they don't accept your PR is how you get the XZ backdoor situation.
There is a different dynamic between this and that.
Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no?
I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.
You could assume that if someone has the technical level to identify a vulnerability and how to exploit it, they probably have the technical level to fix it.
In most cases researchers have no interest in actually "making the software better" and publishing vulns is just a way to increase their cred to land a better job.
FFMPEG's position as a well know very popular open source project means it's very interesting for this type of researcher to find a vuln and put their name on it.
It's an exhausting dynamic.
If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance.
https://news.ycombinator.com/item?id=43140614
It would be interesting to see the results from a fuzzer, developed for FFmpeg style assembly code.
Sure but it seems like most of these vulnerabilities are being found in the C code.
No. They tried that with coreutils and look what happened. More CVEs.
99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake.
In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with those complex decoders operating on data which is often untrusted. I wouldn’t suggest a project of that scale lightly but it’s at least a near-perfect fit on the problem domain.
I would say it’s the opposite. coreutils is core utils, you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. They are also relatively simple.
With ffmpeg, anyone who knows anything about secure application development in the past 20 years knows that it is a huge security tarpit and throwing it untrusted inputs in trusted environment is asking to be owned. You thoroughly sandbox that shit. That’s true for all untrusted media conversion, but absolutely with ffmpeg.
My point about coreutils was that they’re rarely used in situations where an attacker can provide arbitrary input - it’s more like race conditions with code already running on the same system trying to escalate access – so what you need to protect against are things like race conditions around file operations or symlink safety.
> you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments.
True.
That doesn't make them "very exposed to memory safety errors".
The coreutils rewrite was shit because of the license change. Most of the other founding ideas were also bad as you say, but the license change was absolutely a much worse signal. Just a bunch of people rolling over and showing big corps their belly. And for what? So they can be more exploited by people that treat them like cattle.
Rust does not do "nothing" to prevent logic errors. On the contrary, its strong type system makes them much less likely than in C.
Also security isn't the only reason to prefer Rust to C.
But I do agree ffmpeg would see a much bigger benefit from being written in Rust.
Look, I like Rust and ported every bit of C I used to it a decade ago but this is not a compelling argument. The coreutils rewrite is an existence proof that the typing system doesn’t motivate this class of error and a moment’s thought would explain why (you’d have to be very familiar with the attack patterns to know to create types like “handle to private file failing if the name exists” and they weren’t).
What could help would be a modern API implementing the same patterns that GNU coreutils evolved over the last 4 decades but that’d be less the language than the library and it’d only go so far because some of those utilities legitimately need to things which are otherwise rare in most applications.
In case with coreutils, as I remember, there were mostly race conditions. Not memory safety issues. Maybe we just need better I/O libraries.
Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.
Errors are easily found and corrected for a modest one-person project in C.
But we’re combining probability of error creation (which is effectively constant) and the limits of human cognition.
Some things are impossible at one scale, become possible at another, and become inevitable at yet another.
To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.
I personally like to use C and find Rust annoyingly complex. I think it may be an alternative to C++, but C++ is also too complex for my taste. I do not find it annoying to free several allocated structures when there is an error, but one could also automate this with a often used extension.
There is also the question whether trading memory safety against supply chain risks is really worth it.
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?
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 ?
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.
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.
> 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.
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.
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.
Of course. Everybody knows to rather use the obvious alternative to ffmpeg!
> the obvious alternative to ffmpeg
IIRC that is currently sandboxed ffmpeg.
Until the people going on about making an equivalent in pure rust being automatically much safer, stop talking about it and actually get on with making it, of course!
FFmpeg is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain.
It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.
For the implemented formats, wuffs is safer and also often faster: https://github.com/google/wuffs
while sandboxing ffmpeg directly isn't difficult, unfortunately with something like MPV/VLC that uses ffmpeg it's more challenging. until recently (virtio gpu native context) it wasn't even possible to sandbox a video player without losing all hardware acceleration. at least not from the outside, they could always try to sequester ffmpeg and seccomp it to hell like chromium.
Sandboxing not only OS access but also hardware access feels almost impossible to be honest. At least not via user-friendly exec based stuff like bwrap.
Personally, I still try to contain them a bit: https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles
They're also extremely hostile to security researchers who report these issues.
I wouldn't call "nice find, care to help us fix that?" extremely hostile. It can be frustrating for open source projects that far more people want a pat on the back for the identification of a problem (be it security, performance, documentation, or anything else) than there are people who have the time and inclination to help resolve the issue (or ability and inclination to fund the project so it can more easily find help if needed). The use of LLM based tools apparently making that pat on the back easier to attain is going to exacerbate that problem for a while at least.
I don’t deal with ffmpeg or C/asm, but there are certainly some 4gl applications that a random patch may cause more problems than it solves. I imagine many researchers would be in that box.
https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw...
Security is the punch line for ffmpeg.
I'm glad to see their sense of humour :-)
https://nitter.net/ffmpeg/status/2039115531744334180
> Assembly is a human readable version of machine code. It's exactly the same.
goddamn, and this is a project that prides itself on having had-written assembly in it
There's certainly assembly that maps directly to the machine language bytes, I assume you are talking about the version of assembly with the high level loop macros
In some circles, High Level Assembly (HLA) is lovingly called "Mainframe Assembly".
Oh my god! They are so funny and memeable! gets RCE'd
In their defense, the "rewrite it in rust" crowd can be really grating.
Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.
Back in 2004 when free email services like hotmail were limited to 10-15mb, on April 1st the evening standard front page headline, which I saw in the office around 2pm, was something “Google lunched 1gb email”
I couldn’t believe they had fallen for an April fools so hard.
The guy running the twitter account is incompetent but the actual devs are a lot saner I think.
I agree it reflects poorly on them though
> … hostile to security researchers who report these issues.
Do you have an example?
I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.
I've run a bug bounty program for a relatively large corporation and you are exactly right. It's worse in open source, because none of the developers owe a researcher their time. At least in a bug bounty program you've communicated willingness both ways already
I have numerous examples of security researchers being hostile and impossible to work with (but cannot share them unfortunately).
One dude running an X account is not indicative of a community to be honest.
That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.
I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.
The main beef is the noise created around these disclosures instead of sending patches to fix the bugs.
If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.
If there was a nearly inexhaustible supply of Indian security researchers emailing you a nearly inexhaustible supply of LLM slop daily, there is a point where you or I would stop caring too.
ffmpeg is Free Software. You are also free not to use it.
Oddly enough, despite all these endless grievances, no one has come up with a better or more capable tool, certainly not one that is freely available.
Evidently no one cares either, because most implementations of ffmpeg I've seen typically run it as root "because we have to". Don't worry we use Docker bro.
You should rethink this kind of casual racism.
> nearly inexhaustible supply of LLM slop daily,
Actual well written vulnerability reports are not the same as slop.
AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.
Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.
> AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.
Ok but who is going to sift through it all to triage the good bits when you're working on something for free?
> Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation
Who gives a shit about reputation when you're the only game in town?
There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.
Its not as full featured as ffmpeg but I remember hearing about mediabunny, It's a web native ffmpeg alternative, and according to its website, seems to be a lot faster than ffmpeg.wasm
> Ok but who is going to sift through it all to triage the good bits when you're working on something for free?
Its like anything else in open source. Maintainers will do so if they care. Maybe they decide they don't care. That is always their decision to make but there are consequences for the project. Maybe those consequences make sense. Being a maintainer is all about making cost-benefit trade offs.
> Who gives a shit about reputation when you're the only game in town?
Its up to the maintainers whether they care or not. It depends on what they value.
Ultimately if maintainers make decisions that are at odds with what their userbase want, someone eventually forks and people vote with their feet.
Security is a bit different.
Today it's an industry driven by unscrupulous clout-chasers and a commitment to quantity over quality.
There is a difference between going through patches and pull requests vs. the endless stream of LLM-assisted bullshit that has started cluttering security inboxes in the last few years.
Vulnerability researchers don't create the vulnerabilities they report. The vulnerabilities exist whether or not they're reported by "clout chasers".
There is a difference between a proper vulnerability researcher and a clout chaser calling themselves a vulnerability researcher. Research for a start, to assess the problem to see if it is genuine and if so if there are significant mitigating factors (by default or that can be implemented), and checking if it hasn't already been reported, instead of just copypasting some LLM output with minimal review. And to many clout chasers everything they find is a grade A world wrecking highest possible priority "if you don't drop everything else and fix this now you are a kitten murderer and I'm going to release the information to the world in 24 hours" level issue (they know this because they suggested it to an LLM and it told them they were so right).
No there isn't. The vulnerability is either real or it isn't. How you feel about the researchers doesn't enter into it. People angry about vulnerability research have been making this argument since 1992.
> No there isn't.
Yes there is, because:
> The vulnerability is either real or it isn't.
this, exactly: sometimes the vulnerability isn't, or isn't a fraction as serious as it is made out to be because it doesn't affect any sane configuration. And the project contributors don't know this until they've wasted time looking into it, time that could be spent looking into actual serious problems.
The extra problem right now is several people/groups dropping the same set of vulnerabilities with not coordination because they've got this great new tool to garner attention and want to be first. So projects have several things to look into that turn out to be exactly the same thing.
I have no idea what you mean by a "proper" vulnerability researcher and I find the concept faintly offensive. But what do I know?
Nobody is obligating open source maintainers to accept or read these reports.
Plenty of people will loudly state that they are irresponsible for not looking into the reports that they send, so while that isn't a direct obligation it is certainly a punishment, via potential reputation damage¹, for not doing so.
--------
[1] for example, see comments elsewhere in this thread saying things like "maintainers will if they care"
No matter what you do, there will be some group of people that thinks you’re wrong.
It’s up to each of us to decide which peoples’ opinions we actually care about.
> Maintainers will do so if they care.
Caring is only part of the problem. If you are inundated by low quality reports, or many duplicates of what turn out to effectively be the same problem, that you have to sift through to find the useful reports, then by the time you have something actionable you have no time left to take action on it.
The amount of reports coming in, particularly the low/zero quality ones, is apparently growing at a much faster rate than the time volunteers have for dealing with them.
Caring does not magically solve problems without enough people with enough time.
"care" is not a viable metric for prioritising the allocation of a scarce resource.
Yes, and people will sit there and sip tea while waiting for "someone"? For how long?
> Yes, and people will sit there and sip tea while waiting for "someone"? For how long?
Until someone cares enough to do it. This is open source software. When it comes to open source, the golden rule is you either do the things you care about yourself or stfu.
Given the libav fork wasn't all that long ago, it can obviously happen to ffmpeg just as much as it can happen to any other project.
Even before the advent of AI the quality of most reports was depressingly low. Most of your reports will quite simply come from folks in lower-wage countries that broadly don't speak English well and that use a shotgun approach to bug bounties. That means you are receiving a lot of them, they will be hard to read (assuming the information you need is in there at all) and if they get one success out of fifty then for them it is a really good return.
The advent of LLMs has made this a hundred times worse. Both because it makes it easier for most people to create reports that sound good (and so are more effort to dissect) and because people who didn't have to work hard to get any amount of competence are usually more entitled and more rude (the stakes are even lower for them).
It is economically no longer a good idea to run a bug bounty program at all. I honestly question whether or not even having a direct input for such things makes any sense anymore. The volume is becoming so great you need a classical spam filter to plow through it. But that won't work, because they all sound reasonable.
Funny, John Carmack was just admiring the creator of ffmpeg the other day for being a better programmer. https://x.com/id_aa_carmack/status/2064095424420487226?s=46
The majority of code in ffmpeg today isn't written by Fabrice, but also there's multiple axes that people view programming ability on. Some people can write software that will do things you couldn't imagine given the constraints. Some people can write software that is resilient against all malformed input. Sometimes these people are the same people, but frequently they're not.
One thing has nothing to do with the other.
Security vulnerabilities are less about programming ability and more about rigor.
[flagged]
Can't help laughing at a random ad hominem against John Carmack of all people, and about his opinion on a guy who is already widely regarded as an especially talented programmer.
[dead]
I don't think that's fair. There's a lot of talent and grit behind ffmpeg. But for better or worse, getting the code to do what it's supposed to do requires a different mindset than getting it to not do anything else (i.e., to handle malicious inputs correctly).
The developers of ffmpeg are very good at the first thing and not very good at the second. But few people on this planet, if instructed to write a complex video format parser in C or assembly, can produce something that's secure on the first try. The main failing of the ffmpeg team is that they should have spent more time on architectural hardening and mitigations. Most other large projects of this type do.
So all I am hearing is.. Rust
My understanding is that ffmpeg is probably incredibly close to the metal, with tons of assembler mixed in. I imagine doing the same in Rust would include lots of `unsafe` blocks and a similar amount of assembly, so it wouldn't change much in terms of security. Or am I wrong?
Wuffs usually comes up in this context: https://github.com/google/wuffs
So who is someone who's opinion is worth anything to you?
Except yourself, presumably, to me it almost seems nobody is perfect.
On this subject I'd at minimum expect someone with experience in security. Not someone most famously known for making toys that run on computers.
I've seen a lot of things written about Carmack over the last 30+ years, not one comment this casually dismissive until today.
The difficulty in exploiting ffmpeg is getting anyone to use it on your input. Sure, you might pwn a few people, but is it worth the effort?
I use it in WASM on the client and call it a day. It works for our use case, but obviously not most.
Is GStreamer a more secure alternative or does it just get a bit less attention than ffmpeg?
Any multimedia project trying to support a large number of formats, whose usage in the wild differs by orders of magnitude, is going to have code of varying quality (although quality is not strictly correlated with usage: age and complexity are also big factors, among others). GStreamer puts plugins into different categories (-good, -bad, etc.) based on things like the maturity of the code, which helps you judge what risks you are taking. With FFmpeg it is harder to know which formats are more likely to have issues. Of course GStreamer can use FFmpeg, in which case you will also have all of FFmpeg's problems.
In both cases you are best off restricting things to what you actually use.
Gstreamer is a multimedia framework where the user creates media DAGs by placing video/audio/multimedia elements such as demuxers, decoders etc in a pipeline. The framework then takes care of running the media pipeline and handles the data buffering etc.
Within the framework there are multitudes of plugin packages that contain said elements and many of them are built on top of ffmpeg.
From what I understand gstreamer is more about building complex pipelines and plugins, ffmpeg is better at playing some obscure 20 year old video format extremely efficiently so you can watch it compiled for a potato.
Different cases really I think both are good.
That's not really true. Ffmpeg is a Swiss army knife for anything related to digital multimedia (old and new). It is broken into a few libraries but doesn't really have plugins.
Gstreamer has a different model, chaining together plugins. Lots of overlap, but I think Gstreamer only has real traction because some silicon vendors use it.
GStreamer is just a different front end to ffmpeg.
ffmpeg's core functionality (encode, decode, streams, pipes, channels) are all implemented in `libav` which gstreamer links against.
GStreamer doesn’t use ffmpeg’s pipeline at all. It implements a much more advanced directed graph with disconnect, connection and pad negotiation. You can dynamically swap out the entire filter graph during live playback with zero disruption. Swap feeds, outputs, effects… all at runtime.
ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines. You can use “switcher” components but the inputs are still static.
GStreamer is extremely special. The only thing that comes close was Microsoft’s DirectShow, which has since been replaced with Media Foundation which can’t do it. And while DirectShow did support it, it was fragile because many 3rd party filters did not support dynamic configuration.
GStreamer does use ffmpeg, but it just wraps the core encoder/decoder/filter code and discards the streams/graph/pipe part of ffmpeg.
> ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines.
FFmpeg doesn't do “pipelines”. It's a library, not a framework.
It's also a command line tool, where you can design (limited) media graphs: sources, sinks, filters, encoders, decoders, muxers, demuxers. You don't express it as directly as gst-launch's pipeline syntax, but it's very much a pipeline.
GStreamer is not "just a different front end to ffmpeg". GStreamer is a pluggable media graph system.
"GStreamer" doesn't link against libav. The GStreamer plugin "gst-libav" links against libav. If you're not using the gst-libav, you're not using ffmpeg. I'd bet a relatively small amount of GStreamer use cases use gst-libav; I typically see people use e.g x264dec and x264enc (from the x264 plugin) to decode and encode media, or, for hardware encoding/decoding, the v4l2enc and v4l2dec elements (or elements from a SoC vendor's plug-in such as gst-rockchip). It also has its own non-libav elements to handle container formats, pixel format conversion, scaling, etc, which are more natural to use since they're part of the core gstreamer plug-in packages rather than gst-libav.
Doesn't GStreamer mostly use ffmpeg plugins?
In my experience it's mainly run by very grumpy and opinionated Europeans who take pride in having bugs old enough to drink.
> Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content.
You would change your opinion quickly if your browser, apps and TV suddenly stopped supporting videos due to relying on FFmpeg.
What prevents running a data stream in, transcoded data out sandbox with no access to unlimited resources, system files, system stacks, etc.
It's okay for a sandbox to fall over due to bad inputs and poor memory security if it can just be restarted and move onto other streams.
I think Chromium already does sandbox ffmpeg in the renderer process because of their "Rule of Two": https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
Thus:
1. Code which processes untrusted input
2. Code written in unsafe languages like C or C++
3. Code that runs without a sandbox
So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.
I completely agree, with regard for the GP's point about Android TV's with onboard ffmpeg libraries and Addon Apps that call on said libraries (or pull in their own) ..
Cheap arse low resource TVs should either include some form of sandboxing OR the entire device should be treated as a "can fall over" sandbox .. well isolated from any household LAN of consequence, etc.
It seems unlikely that BoxStore Brand Android TVs will be well designed with an eye to security so <shrug> they're an exercise for home net admin masochists and/or an opportunity to market sensible easy to use IoT age routers that come preconfigured to handle bad-device(s).
Am I getting this right, you expect TVs which are running Google TV (Android TV is the old name) to be less secure than TVs which are running a different operating system? I think the opposite is the case, because Google TV is developed by Google, which has a lot of experience with software security, while other TV operating systems are developed by companies which clearly don't have that experience.
There are a lot of "Android like" TVs out there.
Those are running mainly on Google TV. Tizen or webOS are also common but are not based on Android.
Most of them require hardware acceleration from the CPU or GPU and that can potentially be exploited to escape the sandbox. GPUs in particular are difficult to sandbox.
Time to RIIR, then?
I haven't seen that acronym before, but my guess is that it's "Re-Implement In Rust", right?
Usually it's Rewrite it in Rust, but both work I guess
[flagged]
[flagged]
Pretty bad astroturfing
ffmpeg is also rather popular and delivers a lot of functionality. Its unlikely that you don't have it installed.
Yes, there are security issues but quite a few are not ffmpeg itself related - the input is pretty shabby or at least not exactly easy to deal with!
Obviously, they could do with some assistance and I'm sure you and I will both dive in with equal zeal.
Hmm.. "shabby input" that makes software xyz fail is a problem in software xyz itself!
"Validate your inputs" is a common rule. Fuzzing is a thing. Both for good reasons (including security).
The obvious question is, how many of those were the sort that writing in a memory-safe language would make impossible?
They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.
Rewriting ffmpeg in Rust will not solve it. The parts that are memory unsafe in ffmpeg, and similar projects, are not unsafe because C or C++ is inherently unsafe. Instead, it's the CODE that is unsafe. Translating the code (data structures, logic, etc) to Rust does not fix bugs in the code. That code will be littered with "unsafe" code, and of course, it will no longer be maintainable.
I think the industry is optimizing for the wrong thing. Generating thousands of AI-written bug reports is easy, at least with Mythos (preview 1) or GPT-5.5. Getting bugs fixed is the hard part.
A few months ago I started working on a system that finds critical security issues and opens PRs instead of just filing reports. The acceptance rate is sitting at roughly 94% so far. Most of the failures were due to project-specific kill switches or other internal mechanisms that weren’t documented, not because the vulnerability itself was misidentified.
Developers generally seem to prefer this approach. A bug report creates work. A good PR removes work. That sounds obvious, but a lot of security products still stop at the report and call it a day.
> I think the industry is optimizing for the wrong thing.
Indeed: The industry optimizes for speed, time to market, and features, and applies the ostrich model to everything that doesn't bring short-time revenue (security considerations, accessibility, vendor lock-in, interoperability, …)
This has been going on for as long as the industry exists, and now we start to have the proper tools to assess the damage and understand the brittleness of it all.
I think I'm missing something here. Apple software has no open source code, how are you suggesting fixes?
What?
https://github.com/apple
Also, check https://opensource.apple.com/projects/
I genuinely didn't know about their OSS efforts, thanks!
I wouldn't go so far as efforts, so much as legally required publication of 3rd party code they use, or open wrappers to their proprietary libraries
Or .. their operating system and kernels
>The reach of this bug is what makes it serious. Any deployment that points FFmpeg at an attacker-influenced RTSP URL is exposed: media ingest pipelines fetching user-supplied stream URLs, surveillance and CCTV systems pulling RTSP feeds, and transcoding services processing remote AV1-over-RTP sources
Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can imagine this is exploitable today.
Some people might suggest it’s crucial to publish if you’re aware of a serious vulnerability, so that people using the software in a vulnerable way can take steps to mitigate the risk.
You would also need some sort of ASLR leak to make this exploitable
Speaking from firsthand experience: codec and other media processing libraries are some of the easiest software to find address leaks in.
(There are a number of reasons for this, not least being that C makes it very easy to ship partially initialized memory over the wire.)
Speed and security are not good bedfellows. Combine that with really shitty standards and dozens of years of development...
Oh, and licensing. Licensing is the real killer. I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.
Ref: https://www.reddit.com/r/gamedev/comments/5stq8z/mp3_licensi...
Ref: https://www.audioblog.iis.fraunhofer.com/mp3-software-patent...
Sorry I was painting a broad image. I'm also worried about copyright infringement, discovery, someone switching to a different different that requires glpl, etc
You raise a good point. You can substitute "MP3" with any patent-/copyright-/license-laden important media codec and you will face the same issues. Your comment would be very timely in the year 2005, when MP3 licensing was a serious issue for game devs.
I don’t think this is necessarily true! Constraints can be liberating: a language that allows strong encoding of invariants makes it easier for the language’s compiler to optimize.
I agree about long periods of development and difficult standards, though.
> Wow this is actually pretty serious
Don't tranform your ffmpeg instance into a web browser.
ffmpeg has stated many many times that they don't care about bug or security reports
[dead]
Even if this isn't as big a deal as this [advertisement for a security company] seems, it is a reminder that every application you release does have a security hole somewhere, and a script kiddie can now find it 5 minutes after release for $2 in credit. If you're not red-teaming your code before release, hackers are doing it after.
Inflated use of the term zero-day, while none of the described vulnerabilities is actually a zero-day. But it sounds and clicks good.. thank you for the PoC.
That's not what "zero-day" means.
Explain what it means along with your statement. Maybe I have the wrong definition too.
(not op)
If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication.
When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.
Even that's revisionist.
Originally a zero-day exploit was one that was found by crackers on the first day of release of a software product. Like finding a licence crack for a new Microsoft program on the day it went on sale.
There used to be fierce competition to find such an exploit within those 24 hours, and great kudos for those who did.
Nowadays a zero-day can apparently be found years after release, which makes no sense.
Does "publication" refer to the software or to something documenting the existence of the bug? Because I thought zero-day meant the bug was exploited the same day the software containing the bug was released, but your phrasing sounds like if you exploit a bug before the maintainers know about it then it's a negative day.
I did so in the other reply thread of the comment you replied to.
> [Z]ero-day specifically compares when the white hats (vendors, system owners) and the black hats learn about the existence of a vulnerability. If white hats learn that a vulnerability exists by being subject to an in-the-wild black hat exploit of it, then it's a true zero-day.
And, again, you need to be aware that the vulnerability is the flaw or defect in the software or system (e.g., buffer overrun), and the exploit is the specific methodology that takes advantage of it (e.g., worm, malicious web request from a botnet, etc.).
Some people differentiate between a zero day vulnerability and a zero day exploit. I don't really find that is common anymore, and essentially everyone using it means zero-day exploit.
It seems to have lost its meaning after getting popularized following Stuxnet coverage.
No, I think it was since Code Red.
I understand why it's poorly understood. It's a snappy term, and people assume it means "bad" and nothing else because that's all you can get from the context. However, since most people also don't know the difference between a vulnerability and an exploit, they won't understand the definition of a zero-day when they read it.
But I'm still going to complain if a security vulnerability research company is using the term incorrectly in their own press copy. It makes them look amateurish.
> the difference between a vulnerability and an exploit
is it the difference between a knife and a stab wound?
No, that's the difference between exploit (knife) and either the incident or impact (wound). The vulnerability would be a gap in armor.
The vulnerability is the exposed weakness. Vulnerabilities get fixes, and they exist without anybody knowing about them. Vulnerabilities get CVEs assigned to them.
The exploit is the means of attack. It's the specific actions or calls that let you take advantage of a vulnerability. It could be a worm, or botnet scripts, or specifically crafted data[0]. A proof of concept is not an exploit itself, but it demonstrates that the vulnerability can be exploited.
An example of a vulnerability might be a gate where the gap between the door and the jam are too wide. The exploit is a coat hanger used to lift the inside latch from outside the gate. That results in unprivileged access.
And zero-day specifically compares when the white hats (vendors, system owners) and the black hats learn about the existence of a vulnerability. If white hats learn that a vulnerability exists by being subject to an in-the-wild black hat exploit of it, then it's a true zero-day.
[0]: https://xkcd.com/327/
[dead]
> At this point the corrupted free pointer is called, and control of the instruction pointer is ours.
Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
The article glosses over this, but it looks like the next variable in the struct is conveniently the first parameter to the function, so you can run arbitrary code with system() or whatever. But, yeah, you would need some other exploit to defeat ASLR.
I've been using ffmpeg for a very long time, both personally and for services I've built. Fabrice Bellard is a genius, and the developers who have taken it so far have made the world measurably richer.
But I can't think of a program more worthy of sandboxing when run with untrusted input than ffmpeg. It's a huge amount of C dealing with the most complicated video and audio codecs, which is notoriously impossible to get completely right.
But it's not actually that big of a problem. I run ffmpeg inside a VM or gVisor, and the end result is usually a video file that I'm perfectly willing to play in my browser, where it gets decoded in yet another sandbox because this shit is hard.
I glumly predict that copyright-holding companies wanting DRM, "trusted platforms", regulatory capture, etc. will drive some of the damage here.
Secure sandboxing tends to mean opportunities to make unrestricted copies.
What do you mean "video file that I'm perfectly willing to play in my browser". Isn't it safe to assume that no video file can escape the browser decoding sandbox?
> Isn't it safe to assume that no video file can escape the browser decoding sandbox?
Why would that be safe to assume? If that were a reasonable assumption, you could just as well assume that it's safe to run ffmpeg.
I'm not up-to-speed with the current state of sandboxing in browsers, but in principle it's (on modern operating systems) not especially hard for them to sandbox the decoding into a separate process with basically no privileges beyond rendering a video stream. It's a bit trickier if we're only considering demuxing and delegating decoding to the hardware, but that's a much smaller attack surface.
A manually run ffmpeg on the command line does nothing to restrict its privileges, and its security model has very little interest in doing so, while browsers very much have.
Yeah, then you need to stream content in real time between multiple processes. And not screw up the licensing.
And get hardware acceleration working...
The parent does argues it is safer to sandbox ffmpeg yes
Isn't it safe to assume that no video file can escape the browser decoding sandbox?
It's 'safe to assume' it's not. It's emphatically not safe to assume any mitigation is perfect.
No, browsers have had many sandbox escape exploits related to decoding.
But then you also often need hardware accelerators for encoding, so you need to use C again.
The incentives structure is deeply broken in the field of Security Research. They are the middle management of the FOSS world. Celebrated for dumping more work on volunteers. The more urgent the work, the more they are celebrated. Acknowledging the realistic impact of issues or the pragmatic implications of an issue are at odds with their incentives.
It's hard not to see them as bottom feeders of the software industry and I wish we would starting treating them like pariah. Submit the PR or STFU.
Not suprised theres holes in codec implementations. They are extremely complicated structurally. Most modern codecs layer compression features endlessly in the pursuit of better compression. The specs are insanely bloated. Filesystems have the same problems, with huge bloated specs. You wouldn't mount an untrusted filesystem. Theres issues at all levels. The filesystem, the stream muxer, the codec. It would be nice if we could just use some simple uncompressed or lossless compression for video, and not need to have this mess of lossy codecs with endless compression features. But computers/networks still dont have the bandwidth to practically handle uncompressed video in 2026, altho audio can be. I doubt theres many issues with lpcm.
Is the future of defense-against-foreign-agents-on-my-codebase to subtly hide prompt injections into one’s codebase that would defeat agents to find security bugs ?
If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
No...
> DFVULN-123 (Integer Overflow): In the RTP LATM depacketizer (rtpdec_latm.c), latm_parse_packet() performs a signed 32-bit addition that overflows and bypasses its bounds check
Again there is another vulnerability caused by unchecked addition, and still modern languages like Rust or Go do not raise exception on overflow, and modern CPU architectures like RISC-V provide no overflow traps. And older languages like C or C++ do not have overflow checks also.
Ridiculous. It is obvious that humans cannot be trusted with writing correct arithmetics code.
Rust enables overflow checking in debug mode, you can (and I do) enable it in release mode as well.
Rust's default integer overflow in release mode is defined as well, it'll just wrap around. This makes it less likely to result in a vulnerability (unless you start writing unsafe Rust).
Additionally, integer overflow is less immediately dangerous in Rust, because buffer access is bounds-checked after the arithmetic. You can still get some logic bugs that eventually lead to vulnerabilities, but it's not an arbitrary memory write gadget.
What convinced me that this is wishful thinking was CVE-2023-53156. Yes, it used "unsafe" but the wraparound in release defeated the manual check, and when you aim for performance comparable to C, Rust tends to be full of unsafe blocks.
IMHO better C tooling would be a far better investment than rewriting in Rust.
Incremental/quantitative improvement isn't disproven by contradiction. Anecdote is not data. Look at a bigger dataset, e.g. https://github.com/rust-fuzz/trophy-case there's a ton of overflows that result in caught panics or OOMs, and not bypasses. It works to reduce defect rate and severity.
Note that C's tools for this like Valgrind, instrumented allocators and LLVM sanitizers work with Rust too. Investment in catching these in C generally helps unsafe Rust too, but Rust also has Miri, and a much better baseline for static analysis.
... do `unsafe {}` blocks not have the same semantics? I thought that was only about memory safety. Or are you thinking of cases where a wrapped-around integer gets interpreted as a pointer or something?
unsafe never changes the semantics of anything. Unsafe gives you access to additional features, never changes the meaning of a feature.
>modern CPU architectures like RISC-V provide no overflow traps
Irrelevant. Simplicity here is better than complexity.
Unless you're handwriting assembly, this is a compiler's job.
Zig raises overflow. There are +|= and +%= operators for clamped and wrapping addition.
Rust doesn't raise overflow by default. But you can just 123.checked_add(321). Now your code is unreadable, but it's overflow safe.
Honestly, based on the way I write code I'd rather something like an end of line comment. Like:
Because I'm very unlikely to mix wrapped/checked/clamped arithmetic in a single line. It can't be a compiler state like doing(wrapped) { x + y } because in Zig every line must be "compilable" by itself, without requiring context from other parts of the code. Function names are too verbose. Casting is too verbose. Having a statement-level modifier would be a good compromise.Nobody is going to write "checked_add" because that's too long and people are too lazy. The checked addition should be "+" operator.
Agreed, the option that sacrifices security in search of performance should be the more verbose one. There's a reason Rust doesn't have `safe {}` blocks and there's a reason it chose immutable-by-default semantics.
I find difficult to know how serious the issue is, if it is even an issue.
LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.
Most of them involve very weird and unlikely scenarios and bad security practices or access to the ffmpeg binaries and being allowed to run arbitrary commands at an elevated permission.
In and of itself there's not a massive issue from what I can see, they're entry vectors that can lead to worse situations.
That's not to say they're not serious but if a Russian hacking group is using one of them it's in conjunction with other exploits or security flaws. Which is common in practice when it comes to decoding.
Its 21 issues. And they've been human validated, as far as I can tell.
What about VLC's own built-in versions of decoding libraries (I think, from the FFmpeg project)? Is there a scenario here where we may have to deal with malicious MP4 files?
All media containers are potentially hostile. Any offset, extent, or reference has to be considered hostile user-provided input.
Is there a timeline for each of these bugs? I wonder if these bugs had been reported to ffmpeg yet.
Help me understand: depthfirst seems to be bigging up their “security agent” here, but is it not just prompt engineering + writing skill files? What goes into producing a “security agent” beyond this? Feels like they’re really gussying up a process that is ultimately just LLM usage
How does the browser use it ?unless they mean there’s a zero day in libavcodec
Browsers run it in a sandbox process together with allocator hardening. Most of the bugs then are just crashed of the sandbox
Another option is WASM or WASM-style sandboxes if using another process is undesirable.
One chained sandbox escape away from compromise.
Ahah
But are the compiler+OS that runs the ffmpeg executable really a sandbox ?
For executables on Linux there are things like bubblewrap or firejail. One can also use a restrictive container. But those are strictly weaker than browser sandboxes.
The most secure way presently is to use qubes-os that allows to use a very hardened VM to run individual applications.
Which is of course better than zero sandbox escapes.
I just had an unsettling thought… those with access to Mythos/Fable finding these flaws — how many might be holding back and keeping some of these exploits in their back pocket?
Infinity - 21 is still infinity
> A victim only has to run ffmpeg -i rtsp://attacker/stream, the most ordinary command imaginable
What about "ls"?
I had to read your comment a couple of times to understand it. I assume you are saying that "/bin/ls" is the "most ordinary command imaginable"? I think your original quote is saying most ordinary when running ffmpeg, which has a famously complex command line interface.
[flagged]
[dead]
[dead]
[flagged]
Well, get to work then and rewrite, should be quick. Chop-chop!