Google assigns a CVE for libwebp and provides it a ten.0 rating
In case you missed the information, there is a crucial 0day in WebP (a heap buffer overflow within the libwepb library) floating about, which was initially issued as CVE-2023-4863 and assigned specifically to Google Chrome. On the time this occurred, I wrote my weblog put up about it and vehemently tried to make it clear that it wasn’t simply Chrome that was affected, however any software program that makes use of libwebp to render WebP photos.
That story exploded. ????
I’ve simply taken be aware that Google has issued a separate CVE, which is tracked underneath CVE-2023-5129,
With a specifically crafted WebP lossless file, libwebp might write knowledge out of bounds to the heap. The ReadHuffmanCodes() perform allocates the HuffmanCode buffer with a dimension that comes from an array of precomputed sizes: kTableSize. The color_cache_bits worth defines which dimension to make use of. The kTableSize array solely takes into consideration sizes for 8-bit first-level desk lookups however not second-level desk lookups. libwebp permits codes which might be as much as 15-bit (MAX_ALLOWED_CODE_LENGTH). When BuildHuffmanTable() makes an attempt to fill the second-level tables it could write knowledge out-of-bounds. The OOB write to the undersized array occurs in ReplicateValue.
Essential: In case you’re a information individual or somebody who is not certain – this isn’t a brand new bug in libwebp; it is the identical bug as beforehand, however now it has been accurately marked as a bug contained in the WebP Codec and never only a “bug inside Google Chrome”.
And Google just isn’t beating across the bush both; they’ve straight up given it a ten.0 base rating.
And it is what they need to have finished within the first place.
Who’s and is not affected?
The variations affected by this bug are from 0.5.0 earlier than 1.3.2. The kind of software program affected is just about any software program that straight makes use of the WebP Codec to render photos. Simply within the final two weeks alone, outdoors of net browsers (most of which ought to be patched now) – I’ve seen Purple Hat to Debian to software program like Puppeteer and the .NET library for ImageMagick patching it. Truthfully, I don’t know of the total scope of this, and it is not that simple to trace who’s or is not actively patching it.
Ben Hawkes (former Mission Zero supervisor) additionally wrote about this 0day, and he had this to say about it:
The unhealthy information is that Android remains to be seemingly affected. Just like Apple’s ImageIO, Android has a facility known as the BitmapFactory that handles picture decoding, and naturally libwebp is supported. As of as we speak, Android hasn’t launched a safety bulletin that features a repair for CVE-2023-4863 — though the repair has been merged into AOSP. To place this in context: if this bug does have an effect on Android, then it may probably be was a distant exploit for apps like Sign and WhatsApp. I might anticipate it to be fastened within the October bulletin.
Ben’s article additionally has a Proof of Idea instance and different fascinating notes; ensure that to test it out.
However the true query is, why did not Google tag it particularly for libwebp within the first place? I imply, it clearly was a lot broader than simply Chrome (and plenty of information editorials failed to select this up initially), and now they’ve gone forward and assigned a separate CVE.
And it makes me surprise if the perfect factor would not be to merge each CVEs to keep away from any additional confusion.