Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty One Zero-Days in FFmpeg

depthfirst.com

Post reply on HN
Print view View original

201–210 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#201

Post by j1elo »

simjnd wrote: post #127
zerobees wrote: post #19

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 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.

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.

Re: Twenty One Zero-Days in FFmpeg

#202

Post by da_chicken »

journal wrote: post #120
da_chicken wrote: post #28

That's not what "zero-day" means.

Explain what it means along with your statement. Maybe I have the wrong definition too.

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.

Re: Twenty One Zero-Days in FFmpeg

#203

Post by acdha »

anoneng wrote: post #153
acdha wrote: post #144

Earlier quoted context omitted.

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…

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. Y…

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.

Re: Twenty One Zero-Days in FFmpeg

#204

Post by acdha »

IshKebab wrote: post #168
acdha wrote: post #144

Earlier quoted context omitted.

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…

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.

Re: Twenty One Zero-Days in FFmpeg

#205

Post by tptacek »

dspillett wrote: post #198
tptacek wrote: post #175

Earlier quoted context omitted.

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…

I have no idea what you mean by a "proper" vulnerability researcher and I find the concept faintly offensive. But what do I know?

Re: Twenty One Zero-Days in FFmpeg

#206

Post by br0ceph »

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.

Re: Twenty One Zero-Days in FFmpeg

#207

Post by twobitshifter »

jstanley wrote: post #132
zerobees wrote: post #19

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.…

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 w…

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.

Re: Twenty One Zero-Days in FFmpeg

#208

Post by leonidasrup »

ivanjermakov wrote: post #139
codedokode wrote: post #137

Earlier quoted context omitted.

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.

Re: Twenty One Zero-Days in FFmpeg

#209

Post by snvzz »

codedokode wrote: post #142

> 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 o…

>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.

Re: Twenty One Zero-Days in FFmpeg

#210

Post by dspillett »

akerl_ wrote: post #199
dspillett wrote: post #198

Earlier quoted context omitted.

> 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…

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"

Post reply on HN