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

121–130 of 235 posts

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

#121

Post by raverbashing »

winter_blue wrote: post #47
kevincox wrote: post #11

The thing that concerns me most is looking at the fix it is very difficult to see why this fix is correct. It also appears as there is lots of code without explicit bounds checks. It makes me worried because while the logic may be safe this makes the logic very complex. I wonder what the cost would be to add an explicit, local bounds check at every array access. This would serve as a backup that is much easier to ver…

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

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

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

#122

Post by kirbyfan64sos »

michaelmrose wrote: post #69

Remember when it was a problem that 19 flatpaks had 19 different versions of a library. Storage wasn't the primary problem.

Remember when the primary purpose of flatpak's shared runtimes was so that libraries like libwebp are not actually bundled per-application? libwebp in the runtimes has been patched with a fix for over a week.

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

#123

Post by marcosdumay »

mrtksn wrote: post #93
sp332 wrote: post #37

Earlier quoted context omitted.

They need a large runtime and are slow to start up.

Is that true for all memory safe languages? Why?

> Is that true for all memory safe languages?

No. That is true for the list upthread (well, if you consider runtimes measuring a couple of MB "large", it's reasonable but quite arguable). It doesn't have much correlation with any feature.

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

#124

Post by unethical_ban »

izacus wrote: post #85
KirillPanov wrote: post #70

Earlier quoted context omitted.

ye gads man, did you even read the comment you're replying to?

I did - and I'm not sure how adding those checks here would help. Are you proposing a full library reaudit?

$ ./pedant.sh

If you read what they proposed and disagreed with it, then don't ask "What do you propose?" - Argue/debate why you think their proposal, which you read, is not useful.

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

#125

Post by xavxav »

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.

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

#126

Post by Aeolos »

raverbashing wrote: post #121
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…

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?

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

#127

Post by saagarjha »

pclmulqdq wrote: post #94
kevincox wrote: post #79

Earlier quoted context omitted.

They aren't wasted if they are preventing security vulnerabilities. I also wouldn't be surprised if patching, rebuilding and distributing this fixed version of libwebp to all of these devices would be comparable to the extra cost of decoding.

"Preventing security vulnerabilities" is not an unadulturated good (the most secure computer does nothing but checking to make sure it hasn't been breached), and any bounds check that does not actively prevent an intrusion is wasted from a value perspective. Your intuition about the cost of a patch vs the extra instructions in the hot path to check bounds everywhere is also very much wrong: the cost of a patch (which…

The most secure computer does nothing, because checking if it has been breached is attack surface.

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

#128

Post by ninkendo »

steveklabnik wrote: post #111
ninkendo wrote: post #101

Earlier quoted context omitted.

A memory-safe language could have easily resulted in the same vulnerability. In this context, “memory-safe” means it does bounds checking on an array when you try to access an element. But the webp code does bounds checks up-front so that array accesses can be non-checked, to help performance. (If they didn’t want this performance, they could have easily used a std::vector and used bounds-checked access.) The vulnera…

> presumably This is a big presumption. Yes, it could happen. In practice, doing this isn't even the first tool you'd reach for in this circumstance; the compiler can and will eliminate duplicate bounds checks, so if you've hoisted it early, you shouldn't be using unchecked accesses, even if you care about performance, until you've demonstrated why the compiler isn't okay with removing them. The extra ceremony ("unsa…

> The extra ceremony ("unsafe { foo.get_unchecked(n) {" vs "foo[n]" makes this even simpler to catch in code review

Right, and in said code review, the webp author could have easily said “yup, we want unsafe here because we already checked up front that the buffer shall not exceed k elements”. Sure it’s easier to see that unchecked access is happening, but when the whole point of large sections of the huffman table code in webp is to make this very thing work, it wouldn’t cause any additional scrutiny in a code review. In other words, it would already be super clear to the reviewer that bounds checking is being disabled for performance sake, seeing the word `unsafe` as ceremony isn’t really adding any information here.

It’s possible webp could have been implemented in rust with a naive approach to early bounds checking and relying on the optimizer to elide it, but having looked at the code, with all the buffer sizes they’re passing around, it looks unlikely that equivalent rust code would have been able to auto-optimize it. I don’t think it’s unlikely at all that, in this parallel universe, they would have found the bounds checking to be a decent enough overhead that they would have reached for unchecked access, and would have passed code review the same way the current code did.

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

#129

Post by diogenes4 »

winter_blue wrote: post #47
kevincox wrote: post #11

The thing that concerns me most is looking at the fix it is very difficult to see why this fix is correct. It also appears as there is lots of code without explicit bounds checks. It makes me worried because while the logic may be safe this makes the logic very complex. I wonder what the cost would be to add an explicit, local bounds check at every array access. This would serve as a backup that is much easier to ver…

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

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

#130

Post by saghm »

kouteiheika wrote: post #120
secondcoming wrote: post #104

Earlier quoted context omitted.

This response is becoming so tiresome

> This response is becoming so tiresome I'd argue the constant stream of CVEs due to memory unsafety is even more tiresome.

Agreed, I'll stop saying it when we stop having these issues. I don't think people want to confront the fact that there isn't any easier solution, but we're going to keep running into the same thing over and over until we do.
Post reply on HN