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

131–140 of 235 posts

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

#131

Post by ctz »

pclmulqdq wrote: post #75
kevincox wrote: post #41

Earlier quoted context omitted.

I understand that the patch is correct. The point that I am trying to make is that the correctness of this code relies on non-local reasoning (the allocation/reallocation of the table before it is used). I believe that non-local reasoning raises the chance of error (and is likely one of the reasons why this bug existed in the first place). By adding length counts and explicit bounds checks locally you provide local r…

Over a library used by billions of people a lot of times a day, those bounds checks add up to a lot of wasted time and energy if you don't strictly need them. If this is a common function in the webp library, this function is probably called something like a trillion times a day.

I think your intuition on the cost of not-taken bounds check branches is off, especially in the context of devices that spend most of their resources browsing the web, running radios, powering screen backlights. I bet any holistic measurement could not tell the difference.

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

#132

Post by ck45 »

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.

One example for a safer language developed at Google: https://github.com/google/wuffs

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

#133

Post by radlad »

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.

On this note, I was really surprised to find Red Hat's OCI runtime is written in C: https://github.com/containers/crun

Is anyone working on a Rust version?

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

#134

Post by yjftsjthsd-h »

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.

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 mention that this is one reason why I really like wuffs, mentioned elsewhere in this thread; it's a safer language that compiles down to C, so you can have mostly the best of both worlds)

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

#135

Post by xeckr »

malfist wrote: post #77
toomuchtodo wrote: post #64

Earlier quoted context omitted.

This is why I'm bullish on LLMs for application security vulnerability searches (like Shodan for code). It'll see what humans don't.

Why would you expect that? LLMs are explicitly trained on what humans do. Humans miss security vulnerabilities all the time.

Because of generalization.

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

#136

Post by mxkopy »

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?

[flagged]

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

#137

Post by saghm »

izacus wrote: post #100
saghm wrote: post #95

Earlier quoted context omitted.

The best solution to this sort of bug is not using languages that are susceptible to this sort of bug. At the very least, I think it's time to retire the fallacy that we're generally capable of producing sound programs in memory unsafe languages. Just like we don't write code manually checking raw SQL to protect against injections and we don't roll our own crypto when we need to encrypt something or do a key exchange…

You do understand that's not a practical solution here, do you?

Implementing webp and similar libraries in another language may not be quick or easy, but having these sorts of issues continue to crop up over and over doesn't feel particularly practical to me; it's just easier to act like every time a critical vulnerability comes up due to memory safety that it's an isolated issue than confront the reality that its a systemic issue and there aren't any easy solutions.

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

#138

Post by yjftsjthsd-h »

radlad wrote: post #133
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.

On this note, I was really surprised to find Red Hat's OCI runtime is written in C: https://github.com/containers/crun Is anyone working on a Rust version?

Well runc is in Go, which isn't Rust but at least isn't C.

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

#139

Post by aidenn0 »

pclmulqdq wrote: post #75
kevincox wrote: post #41

Earlier quoted context omitted.

I understand that the patch is correct. The point that I am trying to make is that the correctness of this code relies on non-local reasoning (the allocation/reallocation of the table before it is used). I believe that non-local reasoning raises the chance of error (and is likely one of the reasons why this bug existed in the first place). By adding length counts and explicit bounds checks locally you provide local r…

Over a library used by billions of people a lot of times a day, those bounds checks add up to a lot of wasted time and energy if you don't strictly need them. If this is a common function in the webp library, this function is probably called something like a trillion times a day.

The past 40+ years of CS research has created a huge number of tools for reducing the costs of memory safety. Some of these made it into Rust, but others are sitting in (often abandoned) academic projects. It is an abject failure of industry that we are still parsing untrusted input in languages like C.

WebP gets a slight pass because the code is so old; WebP is at least partly based on code from On2 that extends back at least until the early '00s. Rewriting working code is always going to be lower priority than writing new code (and it's not always a safety win either; being deployed for 10 years gets you an awful lot of real-world testing!).

But look at implementations for newer image formats and you see more of the same; C and C++ with the token java implementation that won't get used outside of the JVM.

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

#140

Post by assassinator42 »

pjmlp wrote: post #90
albntomat0 wrote: post #26

Earlier quoted context omitted.

Yes, and so are Python, Lisp, Haskell, and a million other languages that were available in 2010. None of those are suitable options for an image decoding library on the range of WebP supported platforms.

Modula-2, Ada, Object Pascal, D would be. What makes them unsuitabe is lack of widespread compiler support across those platforms, if we ignore how long Ada has been available in GCC. And Modula-2 is now in GCC as well.

Ada has the bounds checking, but doesn't (AFAIK) have a safe way to deallocate dynamic memory. At least as of now, there is a proposal to add something like Rust in the future. It also has memory unsafe concepts like specifying an address for a variable.
Post reply on HN