There's a critical 0day in WebP (a heap buffer overflow in the libwebp library) floating about, which was initially issued as CVE-2023-4863 and assigned specifically to Google Chrome.
This is not a new bug in libwebp; it's the same bug as previously, but now it has been correctly marked as a bug inside the WebP Codec and not just a "bug inside Google Chrome".
That story exploded
At the time this happened, I wrote my blog post about it and vehemently tried to make it clear that it wasn't just Chrome that was affected, but any software that uses libwebp to render WebP images
I've just taken note that Google has issued a separate CVE, which is tracked under CVE-2023-5129,
With a specially crafted WebP lossless file, libwebp may write data out of bounds to the heap. The ReadHuffmanCodes() function allocates the HuffmanCode buffer with a size that comes from an array of precomputed sizes: kTableSize. The color_cache_bits value defines which size to use. The kTableSize array only takes into account sizes for 8-bit first-level table lookups but not second-level table lookups. libwebp allows codes that are up to 15-bit (MAX_ALLOWED_CODE_LENGTH). When BuildHuffmanTable() attempts to fill the second-level tables it may write data out-of-bounds. The OOB write to the undersized array happens in ReplicateValue.
And Google is not beating around the bush either; they've straight up given it a 10.0 base score, Impact score is 6.0, and the Exploitability score is 3.9. It's what they should have done in the first place.
The versions affected by this bug are from 0.5.0 before 1.3.2. The type of software affected is pretty much any software that directly uses the WebP Codec to render images. Just in the last two weeks alone, outside of web browsers (most of which should be patched now) - I have seen Red Hat to Debian to software like Puppeteer and the .NET library for ImageMagick patching it.
Honestly, I have no idea of the full scope of this, and it's not that easy to track who is or isn't actively patching it.
Ben Hawkes (former Project Zero manager) also wrote about this 0day, and he had this to say about it:
The bad news is that Android is still likely affected. Similar to Apple's ImageIO, Android has a facility called the BitmapFactory that handles image decoding, and of course libwebp is supported. As of today, Android hasn't released a security bulletin that includes a fix for CVE-2023-4863 -- although the fix has been merged into AOSP. 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.
But the real question is, why didn't Google tag it specifically for libwebp in the first place? I mean, it clearly was much broader than just Chrome (and many news editorials failed to pick this up initially), and now they've gone ahead and assigned a separate CVE.
And it makes me wonder if the best thing wouldn't be to merge both CVEs to avoid any further confusion.
Image parsing libraries like this are probably the best place where rewriting it in Rust for memory safety makes sense to prioritize. Unsandboxed memory unsafe code parsing data from the internet...
Image parsing libraries like this are probably the best place where rewriting it in Rust for memory safety makes sense to prioritize. Unsandboxed memory unsafe code parsing data from the internet is asking for trouble and it's a shame that this is still so common. I believe within Chrome the image parsing happens within the sandbox it uses for pages, but other applications using this library probably aren't set up as well.
Web browsers dropping an image format that's already standard and supported by all other browsers would be one of the most major web browser compatibility breaks to happen. There's no reason for...
Web browsers dropping an image format that's already standard and supported by all other browsers would be one of the most major web browser compatibility breaks to happen. There's no reason for it to be an either-or situation.
Alex Ivanovs
That story exploded
Correct me if I am wrong, but I thought posting full articles in comments was not allowed due to copyright?
Image parsing libraries like this are probably the best place where rewriting it in Rust for memory safety makes sense to prioritize. Unsandboxed memory unsafe code parsing data from the internet is asking for trouble and it's a shame that this is still so common. I believe within Chrome the image parsing happens within the sandbox it uses for pages, but other applications using this library probably aren't set up as well.
All the more reason to favor jpg XL
Web browsers dropping an image format that's already standard and supported by all other browsers would be one of the most major web browser compatibility breaks to happen. There's no reason for it to be an either-or situation.
Great, now I can't even trust a webp image not to hijack my phone.