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

181–190 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#181

Post by mr_toad »

defrost wrote: post #83
cubefox wrote: post #82

Earlier quoted context omitted.

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

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.

Re: Twenty One Zero-Days in FFmpeg

#182

Post by codedokode »

AlienRobot wrote: post #145
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…

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

Nobody is going to write "checked_add" because that's too long and people are too lazy. The checked addition should be "+" operator.

Re: Twenty One Zero-Days in FFmpeg

#183

Post by zahlman »

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…

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

Re: Twenty One Zero-Days in FFmpeg

#184

Post by codedokode »

uecker wrote: post #170
codedokode wrote: post #143

Earlier quoted context omitted.

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.

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.

Re: Twenty One Zero-Days in FFmpeg

#185

Post by zahlman »

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

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

Re: Twenty One Zero-Days in FFmpeg

#186

Post by zahlman »

codedokode wrote: post #182
AlienRobot wrote: post #145

Earlier quoted context omitted.

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

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.

Re: Twenty One Zero-Days in FFmpeg

#187

Post by xboxnolifes »

LegionMammal978 wrote: post #147
simjnd wrote: post #127

Earlier quoted context omitted.

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

There is a different dynamic between this and that.

Re: Twenty One Zero-Days in FFmpeg

#188

Post by uecker »

codedokode wrote: post #184
uecker wrote: post #170

Earlier quoted context omitted.

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.

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.

Re: Twenty One Zero-Days in FFmpeg

#189

Post by steveklabnik »

zahlman wrote: post #185
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).

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

Re: Twenty One Zero-Days in FFmpeg

#190

Post by shermantanktop »

uecker wrote: post #170
codedokode wrote: post #143

Earlier quoted context omitted.

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.

Post reply on HN