So this could potentially be activated by opening up a WhatsApp or RCSChat that received a payload right? I'm turning off auto download for now
Those apps don't render WebP as far as I know so they should be fine.
Google assigns a CVE for libwebp and gives it a 10.0 score
51–60 of 235 posts
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#52Additional 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…
> Chrome doesn't yet support a memory safe language
In addition to the safety features you mentioned, Chrome supports Wuffs, a memory safe programming language that supports runtime correctness checks, designed for writing parsers for untrusted files. I don’t think it existed at the start of the webp project either, but that’s what I would expect the webp parser to be written in, over Rust or a garbage collected language.
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#53Android 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.
My phone came out in 2017. I'm still on Android 8. There's an update to Android 9.1 available somewhere, but AT&T never got around to porting it to their crapware-riddled fork.
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#54Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#55Earlier quoted context omitted.
Android phones don't have an awful lot of attack surface area for typical users though. Messenger apps already will refuse to display arbitrary images - Whatsapp for example will only display jpegs and mp4's sent from other contacts.
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.
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#56Additional 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…
> Chrome doesn't yet support a memory safe language In addition to the safety features you mentioned, Chrome supports Wuffs, a memory safe programming language that supports runtime correctness checks, designed for writing parsers for untrusted files. I don’t think it existed at the start of the webp project either, but that’s what I would expect the webp parser to be written in, over Rust or a garbage collected lang…
Ahh cool! I was unaware of Wuffs. Thanks for sharing!
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#57Android 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.
My phone came out in 2017. I'm still on Android 8. There's an update to Android 9.1 available somewhere, but AT&T never got around to porting it to their crapware-riddled fork.
Galaxy S8?
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#58Earlier 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.
> 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!
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#59Observation: 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 lookup tables in effect;
C) The software implementing those lookup tables and the decompression side of things were never properly fuzzed, bound-checked, and/or mathematically proven not to create out-of-bounds errors, that is, for every potential use of the lookup table to be guaranteed as correct mathematically given any possibility, any combination of data in an input stream.
Also -- Didn't stuff like this already happen in GIF and PNG formats? Weren't there past security vulnerabilities for those formats?
Isn't this just (I dare to say) -- computer history repeating itself ?
Point: Software Engineering Discipline:
If you as a Software Engineer implement a decompressor for whatever format (or hell, more broadly and generically something that uses lookup tables on incoming streams of data) -- then the "burden of proof" is on you, to prove (one way or another) that it does not have vulnerabilities.
Fuzzing can help, mathematics and inductive/deductive logic can help, testing can help, and paranoid coding (always bounds-checking array accesses, etc.) can help, running in virtual machines and other types of limited environments and sandboxes can help. Running as interpreted code (albeit slower) could help. Deferring decompression to other local network attached resources running in limited execution environments could help.
In short... a monumental challenge... summed up as:
"Prove that all code which uses lookup tables can not generate hidden/unwanted states."
Re: Google assigns a CVE for libwebp and gives it a 10.0 score
#60So this could potentially be activated by opening up a WhatsApp or RCSChat that received a payload right? I'm turning off auto download for now
Does Whatsapp even support webp? Don't they reencode everything as jpeg?
If I recall correctly, Whatsapp supports webp for their sticker packs. And those are open to anyone to develop and integrate in Whatsapp on device with a intent.