Live data from Hacker News

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

stackdiary.com

71–80 of 235 posts

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

#71
post #3

The point about Android is particularly important. I wouldn't like to estimate the proportion of Android phones that are in regular use that no longer receive security updates.

Is there any site that shows what phones are still getting security updates? I'm worried that this will be the thing that makes me retire my son's old Moto G... 5 I think? It's probably out of security updates. Which kills me, he's a careful boy and it's a solid phone, this is unnecessary E-Waste.

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

#72

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 the sort of thing where I am very curious to hear what happens if you fine-tune an uncensored version of GPT4 on some memory exploits like this along with the vulnerable code and ask it for more. It seems like it ought to be really good at this and I am suspicious that people in the know are afraid to talk about it publicly because it's too good at it and once people start weaponizing LLMs for this purpose we…

LLMs should indeed be very good at finding vulns. It is a safe bet state actors have already done this, and have added to their stockpile of zero-day exploits. I suspect you are right that collectively we are whistling past the graveyard and the current "solution" is to make widely available LLMs explicitly not provide that kind of capability.

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

#73

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.

I'm sure this is what you meant, right ;)

https://github.com/Traneptora/jxlatte

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

#74
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?!

It appears so: https://support.google.com/pixelphone/answer/4457705?hl=en#z...

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

#75
post #39

Earlier quoted context omitted.

There was a great explanation a few days back on why the vulnerability existed, and on why the fix was correct: https://blog.isosceles.com/the-webp-0day/ (Discussed in https://news.ycombinator.com/item?id=37600852 )

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.

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

#76

Observation: Uncompressed bitmaps, while bloated in terms of necessary bandwidth, still are provably the most secure form of bitmap -- just as uncompressed video (again, while super-bloaty and bandwidth intensive) would be... That is, to abstract, our security issue exists because: A) There is complex compression/decompression software/code; B) To implement this compression/decompression -- there are one or more look…

Yes, but as counterargument: there are battle-tested compression formats that offer pretty-damned-good compression. If anything, this shows some questions of calculus when it comes to risk-vs-reward of embracing new standards for compression formats. When was the last time there was a serious vulnerability in major JPEG libs? Or even h.264, which is much newer? Yes, a .webp is like 2/3 the size of a similar JPEG, but for most people are JPEG image sizes a huge cause for concern? Once you're doing lossy compression you're already sacrificing fidelity for filesize so you don't see a lot of machine-crushing-huge JPEGs.

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

#77

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.

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

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

#78
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?!

> 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 ends up being kind of silly: if I want to have a mostly secure backup device (for 2FA and my bank/eID apps), then I probably need two comparatively recent devices, since a 5 year old budget phone would no longer quite do as a temporary daily driver, in case I'd lose my main phone.

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

#79

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.

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.

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

#80

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.

Seems to help attackers just as much as defenders though, until you’ve found every single bug (which could be possible, but will likely be expensive.)
Post reply on HN