In case you missed the news, there’s a critical 0day in WebP (a heap buffer overflow in the libwepb library) floating about, which was initially issued as CVE-2023-4863 and assigned specifically to Google Chrome. 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.
Important: If you’re a news person or someone who isn’t sure – 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”.
Update: And just like that… it’s gone! Google has just pulled this CVE and rectified the original CVE-2023-4863 to say that it affects libwebp and not just Chrome. This is also what I implied they should do at the bottom of this article originally.
And Google is not beating around the bush either; they’ve straight up given it a 10.0 base score.
And it’s what they should have done in the first place.
Who is and isn’t affected?
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.
Ben’s article also has a Proof of Concept example and other interesting notes; make sure to check it out.
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 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.
