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.
Google assigns a CVE for libwebp and gives it a 10.0 score
71–80 of 235 posts
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#72The 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…
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#73Earlier 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.
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#74Android 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?!
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#75Earlier 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…
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
#76Observation: 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…
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#77The 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
#78Android 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?!
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
#79Earlier 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 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
#80The 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.