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

101–110 of 235 posts

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

#101

Post by ninkendo »

ojii wrote: post #30
ramesh31 wrote: post #17

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

Hubris and people thinking they can safely code in memory unsafe languages (they can't)

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 vulnerability happened because this up-front bounds checking logic was incorrect.

If we were to hypothesize a counterfactual world where webp was written in rust, presumably the devs would have wanted a similar optimization where they did the bounds checking up-front still, and they would have put the actual array access in an unsafe block to have the same perf optimization. The same bug would have thus happened.

The lesson here is that bounds checking on every element access is probably a worthwhile overhead, no matter what the language is. C++ has safe ways to do this (well, safe-ish… safe for the purposes of this bug at least) with std::vector, and maybe they should just switch to that and eat the performance overhead.

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

#102

Post by izacus »

KronisLV wrote: post #78
matthewdgreen wrote: post #43

Earlier quoted context omitted.

A phone released in October 2020 is about to stop getting security updates?!

> A phone released in October 2020 is about to stop getting security updates?! I actually looked into it, my previous phone was released in June 2020. The last security update for the phone came out in January 2022. I'm not sure whether they're just updating things infrequently or whether that model is abandoned altogether, but neither would speak highly of the Android support landscape for non-flagship phones. This…

Which phone would that be?

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

#103

Post by izacus »

jacquesm wrote: post #46
changelink wrote: post #29

Earlier quoted context omitted.

I just checked, and in the last 30 minutes a update has become available for my Pixel 5. The security bulletin doesn't reference this CVE specifically but does mention a critical vulnerability that could lead to RCE.

The problem is that they'll use the opportunity to schlep a bunch of non-security related stuff into the update as well. That's the thing that really bothers me about these, that you can't say just the security patches and hold the telemetry/marketing/spyware/adware/crapware/malware/etc.

Updates outside the quarterly feature drops on Pixels are pretty much exclusively security patches so I have no idea what you're talking about.

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

#104

Post by secondcoming »

saghm wrote: post #95
izacus wrote: post #45

Earlier quoted context omitted.

[flagged]

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…

This response is becoming so tiresome

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

#105

Post by howinteresting »

ninkendo wrote: post #101
ojii wrote: post #30

Earlier quoted context omitted.

Hubris and people thinking they can safely code in memory unsafe languages (they can't)

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…

While yes, that's theoretically possible, do you have data to establish this? For example, having small sections of the code be marked as unsafe would allow for greater scrutiny of those sections. Also, unsafe access is more annoying to perform in Rust than in C or C++, so maybe that would have acted as a deterrent (or at least the code would have been profiled to make sure that unsafe access was worth it).

https://security.googleblog.com/2022/12/memory-safe-language... shows improvements at scale.

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

#106

Post by jacquesm »

izacus wrote: post #103
jacquesm wrote: post #46

Earlier quoted context omitted.

The problem is that they'll use the opportunity to schlep a bunch of non-security related stuff into the update as well. That's the thing that really bothers me about these, that you can't say just the security patches and hold the telemetry/marketing/spyware/adware/crapware/malware/etc.

Updates outside the quarterly feature drops on Pixels are pretty much exclusively security patches so I have no idea what you're talking about.

This is what I'm talking about:

https://support.google.com/product-documentation/answer/1141...

Good luck setting things up in such a way that you only get security patches and not a whole bunch of 'improvements' to go with them.

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

#107

Post by pixelesque »

Filligree wrote: post #38
Vt71fcAqt7 wrote: post #27

Earlier quoted context omitted.

True, and most websites will reencode images for compression anyway. But the point still stands this makes "hacked by clicking a link" a reality again for some people which should have ended along with flash and java applets. The current mainstream is that "you won't get hacked if you don't install." (not to say that this is the best security practise..) Since you don't install images most people will just assume the…

I hope it does hurt JPEG-XL adoption. The reference implementation is C++, and it’s nearly guaranteed to have equally worrisome bugs in it — every image library has seen those over the years. We live in 2023. We can deal with slightly worse compression until someone rewrites it in a sane language.

It's not just compression ratios that new formats provide though: it's also higher bit depths (meaning less banding for things like gradients, i.e. in skies at sunset) and HDR support (values over 1.0 in 'linear' space, rather than being clamped).

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

#108

Post by e93849 »

ninkendo wrote: post #101
ojii wrote: post #30

Earlier quoted context omitted.

Hubris and people thinking they can safely code in memory unsafe languages (they can't)

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…

Unsafe rust is not a memory-safe language.

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

#109

Post by AnthonyMouse »

saghm wrote: post #95
izacus wrote: post #45

Earlier quoted context omitted.

[flagged]

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…

I feel like we need for C and C++ what Typescript is for Javascript: Not a language from scratch but something which is as close as possible to the thing everyone is familiar with while doing the thing Rust does. A standard library where everything has the same names, the same kind of C++ objects and templates and RAII etc., change only this and nothing else.

Because otherwise you make people learn 100 other things at once to start using it effectively, and then they don't.

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

#110

Post by howinteresting »

matheusmoreira wrote: post #13
api wrote: post #7

Earlier quoted context omitted.

Downvotes of course. Programmers like to think they can write secure code with no guardrails. The fact that CVE lists are full of memory errors in 2023 says otherwise. Even if you can write secure code in unsafe languages, it’s still a problem. Bugs creep in over time as more people work on a project, changes are merged, it’s ported to other platforms, etc. If your project has any longevity you can’t bet on your pris…

We simply don't appreciate other people imposing their will on us. We should be able to start a C project in 2023 without shame if we want to. Simply because we like C and don't like Rust. There's literally no need to justify it any further. We are free to do what we want. If in doubt, remember: the software is distributed in the hopes it will be useful but with ABSOLUTELY NO WARRANTY OF ANY KIND.

Freedom of speech is not freedom from consequences. You can start your project in C and release it on an AS IS basis, and we can make fun of you for it, object to its use in professional contexts, and so on.
Post reply on HN