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

61–70 of 235 posts

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

#61

Post by albntomat0 »

matthewdgreen wrote: post #49
albntomat0 wrote: post #16

Additional timeline info, as I was curious myself. WebP is old enough that a memory safe language was not a feasible option when the project started. Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration]. On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014. As far as I can tell, Chrome doesn't yet support a memory saf…

Is Rust in practice a memory safe language when you're doing tricks like decoding huffman-decoding huffman tables into buffers? It seems like once you optimize for performance this much, you're liable to turn off bounds checking here or there.

I agree it's definitely possible, and I'm certain we'll see a vuln due to some crazy Rust optimizations in the future.

That said, not switching over to a memory safe language, in my opinion, is letting perfect be the enemy of the good. Folks will still be able to write footguns, but better language choices will prevent bugs in the all the non-crazy optimized parts.

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

#62

Post by londons_explore »

sambazi wrote: post #58
Filligree wrote: post #38

Earlier quoted context omitted.

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.

> We live in 2023. We can deal with slightly worse compression until someone rewrites it in a sane language. not just sanity of implementation but also reliability and compatibility {h264,jpg,zip} for life!

Especially when there are various neural net compression methods on the horizon that look like they can probably reduce file sizes 10x or more for similar user enjoyment.

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

#63

Post by antiframe »

matthewdgreen wrote: post #49
albntomat0 wrote: post #16

Additional timeline info, as I was curious myself. WebP is old enough that a memory safe language was not a feasible option when the project started. Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration]. On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014. As far as I can tell, Chrome doesn't yet support a memory saf…

Is Rust in practice a memory safe language when you're doing tricks like decoding huffman-decoding huffman tables into buffers? It seems like once you optimize for performance this much, you're liable to turn off bounds checking here or there.

Rusts bounds checking is done at compile time, so you don't need to turn it off.

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

#64

Post by toomuchtodo »

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…

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

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

#65

Post by jefftk »

matthewdgreen wrote: post #43
nickcw wrote: post #18

Android is particularly troublesome here with the number of phones out there receiving no updates, and just a single download away from being exploited. For me, personally, it's a race to see if Google can get this patched for my Pixel 5 before security updates stop in October.

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

Pixel used to be 3y of security updates. Starting with the 6 (2021) they switched to 5y. https://endoflife.date/pixel

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

#66

Post by baybal2 »

aorth wrote: post #50

> To put this in context: if this bug does affect Android, then it could potentially be turned into a remote exploit for apps like Signal and WhatsApp. I'd expect it to be fixed in the October bulletin. Interesting quote from Ben Hawkes (former Project Zero manager) in the article. I regularly compile Signal-Android from source and happened to notice they vendored libwebp a few days ago: https://github.com/signalapp/…

[dead]

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

#68

Post by Vt71fcAqt7 »

londons_explore wrote: post #55
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…

Clicking a link in a web browser means that any image decoding happens in the browser renderer sandbox. That sandbox is pretty robust - the difficulty of finding an exploit somewhere in a browser renderer is much lower than the difficulty of finding a way out of the sandbox the renderer runs in.

Yes, not exactly "clicking a link" but still at the same level ("add to contacts"). Also many apps have users with profile pictures. An attacker can send a link that will open in an app (eg. Instagram, facebook). Also within browsers could this still leak whatever is currently rendering on the page?

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

#70

Post by KirillPanov »

izacus wrote: post #45
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…

[flagged]

ye gads man, did you even read the comment you're replying to?
Post reply on HN