12 ms·
Twenty One Zero-Days in FFmpeg
- da_chicken 4mo agoThat's not what "zero-day" means.
- nerdsniper 4mo agoIt seems to have lost its meaning after getting popularized following Stuxnet coverage.
- da_chicken 4mo agoNo, 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.
- NooneAtAll3 4mo ago> the difference between a vulnerability and an exploit is it the difference between a knife and a stab wound?
- da_chicken 4mo agoNo, 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/ https://xkcd.com/327/
- jungfty 4mo ago[dead]
- journal 4mo agoExplain what it means along with your statement. Maybe I have the wrong definition too.
- perlgeek 4mo ago(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.
- AlienRobot 4mo agoDoes "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.
- dingaling 4mo agoEven 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.
- da_chicken 4mo agoI 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.
- aaron695 4mo ago[dead]
- bethekidyouwant 4mo agoHow does the browser use it ?unless they mean there’s a zero day in libavcodec
- fpoling 4mo agoBrowsers 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.
- johnnythunder 4mo agoOne chained sandbox escape away from compromise.
- ttoinou 4mo agoAhah But are the compiler+OS that runs the ffmpeg executable really a sandbox ?
- fpoling 4mo agoFor 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.
- loeg 4mo agoWhich is of course better than zero sandbox escapes.
- deleted 4mo ago[deleted]
- nemothekid 4mo ago>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.
- huflungdung 4mo ago[dead]
- akerl_ 4mo agoSome 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.
- skupig 4mo agoYou would also need some sort of ASLR leak to make this exploitable
- woodruffw 4mo agoSpeaking 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.)
- lostglass 4mo agoSpeed 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.
- jacobgold 4mo agoI'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.
- Gehinnn 4mo agoWhat 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?
- thaumasiotes 4mo ago> 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.
- ttoinou 4mo agoThe parent does argues it is safer to sandbox ffmpeg yes
- Denvercoder9 4mo agoI'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.
- wavemode 4mo ago> 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.
- skupig 4mo agoThe 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.
- ttoinou 4mo agoIs 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
- Davidzheng 4mo agoNo...
- fizzynut 4mo agoI 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.
- josephg 4mo agoIts 21 issues. And they've been human validated, as far as I can tell.
- lostglass 4mo agoMost 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.
- zerobees 4mo agoFfmpeg 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-fixes.html 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.
- mr_toad 4mo agoThe 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?
- loeg 4mo agoThey're also extremely hostile to security researchers who report these issues.
- insanitybit 4mo agohttps://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkwEjCgUtFgPYFoX2MRw https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw... Security is the punch line for ffmpeg.
- hootz 4mo agoOh my god! They are so funny and memeable! gets RCE'd
- grahamjperrin 4mo agoI'm glad to see their sense of humour :-) https://nitter.net/ffmpeg/status/2039115531744334180 https://nitter.net/ffmpeg/status/2039115531744334180
- bayouborne 4mo agoWhat 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?
- jeffbee 4mo agoAll media containers are potentially hostile. Any offset, extent, or reference has to be considered hostile user-provided input.
- omoikane 4mo agoIs there a timeline for each of these bugs? I wonder if these bugs had been reported to ffmpeg yet.
- Philpax 4mo ago[flagged]
- izacus 4mo agoWell, get to work then and rewrite, should be quick. Chop-chop!
- lschueller 4mo agoInflated 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.
- tom_ 4mo ago> A victim only has to run ffmpeg -i rtsp://attacker/stream, the most ordinary command imaginable What about "ls"?
- throwaway2037 4mo agoI 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.
- kodt 4mo agoInfinity - 21 is still infinity
- 0xbadcafebee 4mo agoEven 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.
- jungfty 4mo ago[dead]
- appleappleapple 4mo agoHelp 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
- deleted 4mo ago[deleted]
- guessmyname 4mo agoI 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.
- rcbdev 4mo agoI think I'm missing something here. Apple software has no open source code, how are you suggesting fixes?
- tkocmathla 4mo agoWhat? https://github.com/apple https://github.com/apple
- hanzewei_asa 4mo ago[flagged]
- deafpolygon 4mo agoI 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?
- codedokode 4mo ago> 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.
- AlienRobot 4mo agoZig 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.
- codedokode 4mo agoNobody is going to write "checked_add" because that's too long and people are too lazy. The checked addition should be "+" operator.
- zahlman 4mo agoAgreed, 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.
- heinrich5991 4mo agoRust 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).
- techscruggs 4mo agoThe 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.
- br0ceph 4mo agoNot 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.