The September 2023 Patch Tuesday highlighted several vulnerabilities being exploited by attackers in the wild. One of the more significant bugs was the disclosure of a critical heap buffer overflow zero-day vulnerability (CVE-2023-4863) in WebP. The vulnerability exists in the software library that renders WebP images and affects all applications that use this library. Examples of impacted applications include web browsers like Google Chrome and Microsoft Edge, but also desktop applications that handle WebP images. Notably, the exploit can be triggered by rendering a malicious WebP image. In many attack scenarios this requires little or no user interaction, for example, when an image is loaded while browsing the web, or when opening an image locally. For end-users who are not already protected by an application containment solution for browser (such as HP Sure Click Enterprise – Secure Browser) or productivity document-borne exploits, it is particularly important to understand the exploit risks and patch systems. This blogpost discusses the vulnerability and attack vectors in more detail.

Encoding and decoding images

Whenever images are used on web pages, they are encoded and compressed. The goal is to reduce the file size of images so they are loaded as quickly as possible while preserving image quality. When compressing images, there are two different approaches: lossy and lossless. Lossy compression removes parts of the original file that cannot be restored during decompression. The higher the compression level, the more information is irreversibly removed and the more noticeable the fall in quality. On the other hand, with lossless compression the original file can always be restored when decompressing, without any loss of quality. Because of this property, images using lossless compression are larger than lossy-compressed ones.

Knowing about decompression methods is important because CVE-2023-4863 was found in the way WebP images are decoded using a lossless method. It is not uncommon to find vulnerabilities like this in implementations of complex compression techniques. Vulnerabilities in decoders have a long and inglorious history. Over many years, critical vulnerabilities have been found in all kinds of decoder implementations, handling formats as diverse as images, archives, audio and video. Modern fuzzing techniques can certainly help find such vulnerabilities, but it is safe to assume that there are still plenty out there to be found.

The WebP codec

WebP is a codec library for encoding and decoding images. Comparing WebP’s lossless compression with the PNG format, which also uses lossless compression, its images are on average 26% smaller. This makes WebP attractive for web applications due to better loading times. Since the WebP codec is open source, we can see the code modifications that patched the vulnerability. The modifications mainly focus on the implementation of Huffman coding.

Huffman coding

Huffman coding is a common technique in lossless compression. The idea is to create a lookup table where codes are assigned to symbols. In the case of an image, a symbol corresponds to a pixel’s intensity. Frequently occurring symbols are assigned short codes and less frequently occurring symbols are assigned longer codes. The implementation of this coding is however not that simple, since each code must be decoded unambiguously to the correct symbol. Because variable length codes are used, each must have a unique prefix to be correctly decoded. The Huffman coding is thereby also called a prefix code.

Figure 1 – Example of a Huffman lookup table

The result of a Huffman coding is a lookup table, which is used for decoding and a bit sequence, with a string of Huffman codes.

Figure 2 – Resulting Hoffman code string

When decoding a Huffman coding, a defined number of bits are read step by step. Usually, the number of bits corresponds to the length of the longest Huffman code. In our example, this is 3 bits and gives us “000” as the first sequence.

Figure 3 – Reading the first sequence

This sequence is now searched in the lookup table to decode the corresponding symbol. If we however look at our initial table, we cannot find this Huffman code. Therefore, we must extend the table to decode the correct symbol. Because the prefix of each code is unique, the extension can be done without problems. The resulting table looks like the one in Figure 4.

Figure 4 – Example of the extended Huffman table

In this table, our sequence “000” can now be found and the first symbol “H” has thus been successfully decoded. With the help of the prefix length from the table we get the effective length of the searched Huffman code. This is important to correctly decode the next bit sequence. In our example, the prefix length of the Huffman code “000” is two.

Figure 5 – Matching code in the lookup table

This means that the third bit from the first sequence must reused in the next sequence. Therefore, only 2 additional bits must be read in the next step. We get the second bit sequence “011”.

Figure 6 – Reading the second sequence

Again, we search for this Huffman code in the table and thus decode the symbol “P”. Following this procedure, the entire code is decoded step by step.

Figure 7 – Matching code in the lookup table

To improve the decoding efficiency, the generated codes are used as indices of a table, which point to the correct symbol. This way, we do not have to search the entire table for the Huffman code but can directly access the correct entry via its index. The extension of our initial table with additional entries optimizes performance but can lead to very large tables. The more different symbols that occur, the longer the assigned codes become. And because they are used as indices of the table, it grows in the power of two to the length of the code.

To resolve this problem, second-level tables are usually used. A maximum code length is defined and all symbols up to this length are encoded directly in the first table. All symbols, which were assigned to a longer code, are encoded in a secondary table, and linked using pointers. However, since these codes are not accessed that often due to the frequency assignment, the performance loss is only small.

If we rebuild our Huffman code table using a second-level table and reduce the initial index length to 2 bits, we will get the following tables. As you can see, we have significantly reduced the table size, which has an even bigger impact when there are many different symbols.

Figure 8 – Rebuilt lookup table to use a second-level table

In summary, we have a set of symbols that are assigned to codes in order of frequency. These are stored in a lookup table with the corresponding code as an index and can thus be queried during decoding. If the code exceeds a certain length, it is no longer stored in one single table, but is extended with second-level tables. To learn more about Huffman coding, read this article.

The vulnerability

If we look closely at the changes in the patched code of the WebP codec, we primarily see modifications in the implementation of how the second-level table is allocated and filled.

To store the generated table, memory must be allocated by the process that renders the image file. Ideally, the allocated memory matches exactly the size of the table. However, since calculating the size of the resulting table is very time-consuming, a fixed amount of memory is allocated instead. It is assumed that this defined size will be large enough to contain the generated table and won’t be exceeded.

But since the input for the Huffman table is controlled by the attacker and thus comes from an untrusted source, the resulting table can be extraordinarily large. To exploit the vulnerability, part of the table is written beyond the allocated memory area, which overwrites other values in memory. This is called a heap buffer overflow, a sub-class of the very common buffer overflow vulnerability. Attackers can craft malicious WebP images to overwrite memory that should be inaccessible and thus influence the control flow of the process. Ultimately, this can enable an attacker to execute code within the process to achieve malicious objectives, such as exfiltrating data or installing malware.

The patch

The patch, released on 7 September, fixes the vulnerability by preventing the overwriting of memory outside the allocated area. For performance reasons, a fixed size of memory is still allocated. However, when creating the Huffman table, the resulting size of the table is calculated in the first step without writing actual data to the allocated memory section. If the table exceeds this size, the creation is aborted, and the image cannot be rendered. This prevents an out-of-bounds write and mitigates the vulnerability.

The impact and possible attack vectors

Many developers rely on the libwepb library to support WebP in their applications, rather than implementing their own codec. This is convenient for developers, but it can lead to many devices being exposed if a vulnerability exists in a popular library. In this way, the vulnerability affects not only one specific program but lots of different applications.

One way to exploit the vulnerability is to use online advertisements. Attackers could place a specially crafted WebP image containing the exploit in the online ad. The victim then only has to visit the website to cause the image to load and the vulnerability to be exploited. Due to the architecture of modern web browsers, the exploit code is executed in the browser’s built-in sandbox. However, attackers are very adept at chaining exploits to escape the sandbox and infect the victim’s host system.

Currently, many popular web browsers, image viewers and editors and other desktop applications are affected by CVE-2023-4863. In short, any applications that render WebP images using a vulnerable version of the library.

The high number of impacted applications gives attackers the opportunity to exploit this vulnerability by many vectors and significantly extends the window of vulnerability. Documenting every software component and their patch level in relation to this vulnerability will prove challenging for the best of security teams.

Isolating images to protect users

It will take considerable time to patch every application using the vulnerable WebP implementation. The fact that the vulnerability is already being exploited by attackers in the wild is not reassuring either. However, there are prevention technologies like application isolation that help to mitigate vulnerabilities like this one, even before a patch exists.

But it is important to note that not every type of application isolation protects against this vulnerability. For example, certain remote browser isolation approaches do not stop such attacks.

With remote browser isolation technology, the website is not rendered locally, but remotely on a server. A “neutralized” version of the web page is then passed on to the client and rendered again in the local browser. This method prevents the download of malware or the execution of exploit kits. If images are however passed from the remote browser isolation to the local browser in their original form, this does not protect against the current vulnerability and can still lead to a compromise.

HP Sure Click Enterprise isolates web browsing sessions inside secure micro-VMs, so users are protected from this vulnerability. If a user encounters a malicious WebP image while browsing, the exploit runs in a hardware-enforced container isolated from the host PC. This prevents the host system from being compromised and sensitive data being leaked. Furthermore, this approach can extend to other desktop applications too. To protect against malicious WebP image files downloaded from risky locations like the web, HP Sure Click Enterprise customers can customize their policy for added protection. You can find further guidance and example configurations in this knowledge base article: Protect against malicious WebP image files (hp.com)

Conclusion

There have been many vulnerabilities affecting decoders over the years. Despite advances in fuzzing, new bugs like this one surface periodically. Given the popularity of the affected WebP library, it’s likely to be some time before every impacted application is patched. HP Wolf Security’s application isolation technology protects against zero-day vulnerabilities like CVE-2023-4863 – even before a patch exists – by isolating risky activities and attack vectors such as web browsing, opening email attachments, clicking links, and downloading files.