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

161–170 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#161

Post by heinrich5991 »

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…

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

Re: Twenty One Zero-Days in FFmpeg

#162

Post by dspillett »

tptacek wrote: post #71
naturalmovement wrote: post #62

Earlier quoted context omitted.

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

Re: Twenty One Zero-Days in FFmpeg

#163

Post by RetroTechie »

gerdesj wrote: post #29
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 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).

Re: Twenty One Zero-Days in FFmpeg

#164

Post by pornel »

heinrich5991 wrote: post #161
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…

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.

Re: Twenty One Zero-Days in FFmpeg

#165

Post by RossBencina »

mr_mitm wrote: post #128
HappMacDonald wrote: post #118

Earlier quoted context omitted.

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

Re: Twenty One Zero-Days in FFmpeg

#166

Post by IshKebab »

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

Sure but it seems like most of these vulnerabilities are being found in the C code.

Re: Twenty One Zero-Days in FFmpeg

#167

Post by RossBencina »

bawolff wrote: post #61
naturalmovement wrote: post #37

Earlier quoted context omitted.

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

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

"care" is not a viable metric for prioritising the allocation of a scarce resource.

Re: Twenty One Zero-Days in FFmpeg

#168

Post by IshKebab »

acdha wrote: post #144
cryo32 wrote: post #138

Earlier quoted context omitted.

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…

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.

Re: Twenty One Zero-Days in FFmpeg

#169

Post by uecker »

pornel wrote: post #164
heinrich5991 wrote: post #161

Earlier quoted context omitted.

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.

Re: Twenty One Zero-Days in FFmpeg

#170

Post by uecker »

codedokode wrote: post #143
cryo32 wrote: post #138

Earlier quoted context omitted.

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.

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.
Post reply on HN