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

Google assigns a CVE for libwebp and gives it a 10.0 score

stackdiary.com

Post reply on HN
Print view View original

191–200 of 235 posts

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#191

Post by pornel »

ninkendo wrote: post #184
pornel wrote: post #162

Earlier quoted context omitted.

> If we were to hypothesize a counterfactual world where webp was written in rust You don't have to hypothesize. It's here: https://github.com/image-rs/image/blob/master/src/codecs/web... and it doesn't use unsafe indexing.

That’s not google’s webp library, that’s a totally different project. It doesn’t really matter what that project does.

You’re arguing about a potential vulnerability in a hypothetical code that exists only in your imagination.

Meanwhile the real code that exists doesn’t work like that. It’s not just a matter of personal style. Rust has constructs that help avoid bounds checks. It has design patterns that move unsafe code into smaller, easier to verify helpers. It has a culture of caring about safety – people don’t rewrite projects in Rust to just give up on its biggest selling point.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#192

Post by hot_gril »

hgs3 wrote: post #190
ramesh31 wrote: post #17

How can buffer overflows still be happening in this day and age?

Buffer overflows are bugs. You're asking how bugs can still be happening in this day and age? The answer is inadequate testing and broken engineering processes.

The question is how buffer overflows can still be happening, not bugs in general. No matter how bad my eng practices are, I cannot create a buffer overflow bug in a memsafe language.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#193

Post by hot_gril »

xavxav wrote: post #125

I'm tired and cranky today so this will lack subtlety, but: You don't have to use Rust but you **can't** use C. There's no reason to be finding these bugs in 2023; period, we can do better and we know how to do better, there's just no reason apart from legacy code (and even then) that you should be using memory unsafe languages in production.

I don't think the answer is to do fine-grained bounds checking absolutely everywhere, nor do I think it'll happen anyway. Even "unsafe" code has a coarse type of bounds-checking, the kernel's virtual memory layer, which adds less overhead. C etc is fine if it's not in the same memory space as the safe code.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#194

Post by pornel »

hot_gril wrote: post #172
vacuity wrote: post #168

Earlier quoted context omitted.

It isn't, but there's a big difference between writing straight C and writing some unsafe Rust with safe wrappers. It's generally possible to have comparably few lines of unsafe Rust that do the heavy lifting and can be verified to maintain memory safety without sacrificing performance.

Well, the code you mark unsafe is probably also the most complicated piece and thus the most likely to have a bug. I can trust decent C devs to write their basic logic safely, just not the hyper-optimized portions.

A big blob of complex unsafe code is the opposite of how Rust devs approach unsafe optimizations.

Rust has a pattern of isolating unsafety into small components behind a safe interface, so that the component can be understood and tested in isolation. For example, if you need some adventurous pointer arithmetic, you write an Iterator for it, rather than do it in the middle of a complex algorithm. This way the complicated logic can be in safe code.

It's sort of like Lego, where you build from safe higher-level blocks, but you can design custom blocks if you need.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#195

Post by hot_gril »

pornel wrote: post #194
hot_gril wrote: post #172

Earlier quoted context omitted.

Well, the code you mark unsafe is probably also the most complicated piece and thus the most likely to have a bug. I can trust decent C devs to write their basic logic safely, just not the hyper-optimized portions.

A big blob of complex unsafe code is the opposite of how Rust devs approach unsafe optimizations. Rust has a pattern of isolating unsafety into small components behind a safe interface, so that the component can be understood and tested in isolation. For example, if you need some adventurous pointer arithmetic, you write an Iterator for it, rather than do it in the middle of a complex algorithm. This way the complica…

Likewise, C code will be organized into separate pieces with a few small super-optimized/complicated parts, and they can fuzz-test the complicated pieces that are most likely to have buffer overflows.

I can't find the actual code causing the libwebp vulnerability, so idk if mixed safe/unsafe Rust code would've been any better here. Maybe what we really need is an "unsafe-jail" block in Rust that uses a child process limited to a piece of shared mem, and you put big pieces in there to avoid overhead. Like, libwebp can screw up all it wants, just don't touch the rest of my app.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#196

Post by ryukoposting »

samtheprogram wrote: post #57
ryukoposting wrote: post #53

Earlier quoted context omitted.

My phone came out in 2017. I'm still on Android 8. There's an update to Android 9.1 available somewhere, but AT&T never got around to porting it to their crapware-riddled fork.

Galaxy S8?

LG V35.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#197

Post by ninkendo »

pornel wrote: post #191
ninkendo wrote: post #184

Earlier quoted context omitted.

That’s not google’s webp library, that’s a totally different project. It doesn’t really matter what that project does.

You’re arguing about a potential vulnerability in a hypothetical code that exists only in your imagination. Meanwhile the real code that exists doesn’t work like that. It’s not just a matter of personal style. Rust has constructs that help avoid bounds checks. It has design patterns that move unsafe code into smaller, easier to verify helpers. It has a culture of caring about safety – people don’t rewrite projects in…

We know that the webp project does use unchecked access. We know this is intentional because they go through a lot of effort to do up front bounds checking rather than at every access. We also know that companies like Dropbox, when implementing their own Huffman table implementation, demonstrated an 11% speed up when disabling bounds checks: https://dropbox.tech/infrastructure/lossless-compression-wit...

It is not a stretch whatsoever to assume that a direct rewrite of the webp library into rust would have uncovered the same perf findings that Dropbox did, and decided that the pattern of “up front bounds checks, disabled bounds checks at element access” is a reasonable perf enhancement, especially for a Huffman table, where you’re continually accessing the compression table over and over when expanding it.

Edit: the more I think about it, you’re probably right. I had mistakenly thought I was reading C++ code when I was looking at the original patch to the vulnerability. The fact that it’s actually written in C, erodes my argument quite a bit… my logic in my head went something like, “if they wanted bounds checking they would have used std::vector”, but now I realize that’s impossible since it’s not C++. I’ll concede that there’s no real reason to assume that they would have skipped bounds checking if written in a safe language.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#198

Post by hot_gril »

colejohnson66 wrote: post #145
yjftsjthsd-h wrote: post #134

Earlier quoted context omitted.

For an image decoding library, you'll still need to expose a C API if you want anything to be able to use your library. You could only provide a library for your preferred language(s) but if like Google you're trying to push an all-new format the ecosystem buy-in is a big deal. And obviously you can provide a C-compatible library without writing the library in C, but it's more complexity to handle. (Edit: I should me…

If you want a C-style API, that can be had in Rust as well: https://stackoverflow.com/questions/71904069/how-can-i-expor...

Can vouch for the ease of Rust-C FFI. It was very simple for the newbie I was at the time I used it.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#199

Post by eqvinox »

Aeolos wrote: post #126
raverbashing wrote: post #121

Earlier quoted context omitted.

Only goes to show that C is a broken language and unfit for its purpose in today's day and age

For people downvoting, could you please explain which part of this statement you agree or disagree with?

The design of io_uring has nothing to do with the language the Linux kernel is implemented in. And safer languages really can't provide guarantees when the issue at hand is designing a shared memory cross-executable (kernel⋄userspace) API.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#200

Post by eqvinox »

diogenes4 wrote: post #129
winter_blue wrote: post #47

Earlier quoted context omitted.

> ...isn't a solution to memory unsafe languages and libraries. If anything the massive amount of bugs found via fuzzing should scare us as it is likely only scratching the surface of the vulnerabilities that still lie in the code Yup. For example, the Linux code for its relatively new[1] io_uring subsystem was so memory-exploit-ridden that Google disabled it for apps on Android, and entirely on ChromeOS, and their s…

Kind of crazy we're still using monolithic kernels in 2023. Nothing about `io_uring` needs to happen with elevated privileges. I would take a large—say, 2-5x—performance hit just to escape these kinds of vulnerabilities.

A 2-5× performance hit is also a 2-5× CO₂ hit, and I wouldn't be willing to let myself or other people take that hit. We're throwing enough heat into the atmosphere already to make cats dance on our portable supercomputers as is.
Post reply on HN