Critical Vulnerability: WebP Heap Buffer Overflow (CVE-2023-4863)

The Ģ��TV team is currently investigating , a heap buffer overflow in the WebP image encoding/decoding (codec) library (libwebp). Threat actors are exploiting this critical vulnerability in the wild, which affects anything using the libwebp library version prior to 1.3.2.��

This is a rapidly evolving situation, and we will update this blog post with information we receive and confirm—but here’s everything we know so far:

What’s Happening?

WebP is a common image format that supports lossless and lossy compression for web-based images. It is similar to the JPG, PNG, and SVG formats and is natively supported by most common web browsers like Google Chrome, Safari, Firefox, and Edge.
The attack is accomplished by presenting a crafted WebP lossless file to software using libwebp, which triggers an out-of-bounds write to the heap during image decoding and can potentially lead to denial-of-service or remote code execution.
Ģ��TV confirms that our products are not affected by this vulnerability at the time of writing this post.‍
The Ģ��TV research team has reproduced the original proof of concept as outlined in and triggered the buffer overflow in a lab setting, but we have not proven any weaponization of this buffer overflow at the time of writing this.
The confirms “Google is aware that an exploit for CVE-2023-4863 exists in the wild.”‍
At the time of writing this post, there is no public proof of concept for full weaponization of this vulnerability. The Ģ��TV team is actively monitoring for one.
Don’t panic! Patch.

Recommended Remediation

Ģ��TV recommends that partners identify applications that use libwebp and patch them to the latest versions. The vulnerable version of libwebp may be bundled with software that your company uses. You may need to wait until software vendors incorporate the patched library and push out the new version.

If your organization uses the affected version of libwebp in production, you should update it to the latest version.��

This vulnerability is likely widespread, and a full list of affected software is not yet available. libwebp is used in most electron-based applications, web browsers, and many other applications. Identifying which applications are impacted will take time and we may need to rely on vendors self identifying and patching.��

Right now, the most prudent step to take is to update any web browsers and ensure you have a solid software inventory that includes software versions. Being able to quickly identify where you have vulnerable versions of software as patches are released will greatly reduce your risk.

Timeline

On September 7, 2023, that referenced “Fix OOB write in BuildHuffmanTable” in its commit message. This commit patched an issue in Chromium’s libwebp library. Libwebp is a WebP codec that supports the use of WebP images for Chromium. This commit message implies the existence of a memory corruption vulnerability in this codec library in versions released prior to the fix.

On September 21, 2023, researcher Ben Hawkes released a that outlined his successful attempt to trigger the memory corruption and execute a buffer overflow in the vulnerable version of libwebp. At this point, his writeup referenced this vulnerability as CVE-2023-4863, which scoped this memory corruption vulnerability to Google Chrome prior to version 116.0.5845.187. A secondary CVE was also published for the libwebp library itself (CVE-2023-5129) on September 27, 2023, but was quickly rejected as a duplicate of CVE-2023-4863.

As of September 28, 2023, the now scopes this vulnerability to “libwebp in Google Chrome prior to 116.0.5845.187 and libwebp 1.3.2”.

What Does CVE-2023-4863 Affect?

A full list of affected software is still unknown at this time. Any software that uses the vulnerable library is likely affected. Due to the prolific use of libwebp as a software library, the attack surface of this vulnerability is likely extensive.

The patch to libwebp 1.3.2 fixes this issue upstream of its implementation. However, any software that ships with libwebp is potentially vulnerable. Software maintainers have also issued patches for their own products. Initial reconnaissance indicates that the following platforms have issues fixes for this vulnerability:

Common web browsers like Google Chrome, Mozilla Firefox, Mozilla Thunderbird, Brave, Tor, Opera, and Vivaldi.
Major operating systems like Debian, Ubuntu, Alpine, Gentoo, SUSE, Oracle, and Amazon have issues fixes for packaged software components.
Electron, Telegram, 1Password, and other desktop client applications.

Technical Details

The vulnerability is in the implementation of libwebp’s lossless compression algorithm which is used to restore a picture’s pixels with 100% accuracy. This algorithm is called and performs frequency analysis on the pixels for the given input to encode repeating sequences into smaller outputs. The decoder can then restore the pixels based on the coded sequences of bits. This way, a WebP image can be resized, compressed, and reconstructed with perfect accuracy.

Libwebp’s implementation of Huffman coding uses tables to keep track of the map between codes and their values. This table itself is also compressed and present in an encoded WebP image. Memory is allocated to the heap with a pre-calculated buffer size when the Huffman table is constructed during decoding. The buffer overflow is triggered by pushing the pointer to a Huffman table past this pre-allocated buffer size when libwebp attempts to decode untrusted input.��

Practically speaking, this means that an attacker can build a WebP image that forces the decoding algorithm to write out of the bounds of its initial memory allocation. Theoretically, this means that no user input is needed to trigger this buffer overflow. The payload would only need to be consumed by an instance of software using the vulnerable libwebp library. Rendering an image after decoding it in a web browser is one example of a potential attack vector. There are likely many others.

The Ģ��TV research team has reproduced and verified the proof of concept from the original writeup, but has not proven any further weaponization for the buffer overflow.

Ben Hawkes, the author of the proof of concept, remarked that “...even with only partial control of the value being written, it definitely looks exploitable.” There is no public proof of concept for a full exploitation chain for this vulnerability at the time of this blog’s publish date.

What Is Ģ��TV Doing?

We at Ģ��TV have done our due diligence and checked our products for use of the affected library. We confirm that no Ģ��TV products use the affected library.

The Ģ��TV research team has independently verified. We have recreated the buffer overflow in the affected version of libwebp by using the crafted WebP file from the writeup.

At this time, we have not developed this proof of concept into a full exploit that can perform remote code execution. We are actively monitoring our intelligence channels for a public proof of concept for a full weaponization of this exploit. No such public proof of concept exists at the time of publication.

Special thanks to Matt Kiely and James Mason for their contributions to this writeup.��