Resolving Webp Zero-day Vulnerability CVE-2023-4863

Executive Summary

The webp image library is vulnerable to Heap Buffer Overflow. The exact steps to exploit the vulnerability have not been disclosed publicly. The NSO group was actively caring out a campaign which infected Apple devices with spyware, which was disclosed by Citizen Lab. It was later discovered that the root of this attack is in the webp library, which exists in many popular applications such as Google Chrome and the Electron Framework. This vulnerability can be detected with Veracode SCA and Veracode Container scanning. We give guidance for testing and remediation below.

How to Detect and Remediate 

Option 1: Use one of the Veracode SCA scanners; Upload & Scan or Agent-based scan. We are able to detect the following uses of webp: 

1. Webp from OS package manager 

   • An example is this alpine package  

2. Electron declared as a dependency in package.json or code included in the node_modules directory 

3. Python Pillow library 

To patch an application update to the suggested fixed version. If you are compiling webp from source, ensure you include the latest patches available in the 1.3.2 release.  

Example SCA Agent Scans 

In this example, I use the nuget package manager to install three libraries which include webp, and scan using the Veracode SCA agent.

Next, I scan JavaScript libraries. The package.json dependencies section looks like this. 

"dependencies": { 
  "electron": "^27.0.0-beta.1", 
  "sharp": "0.32.5", 
  "@napi-rs/image": "1.6.1"

Agent advises us that we are using vulnerable libraries which include webp. 

Option 2: Scan your container image, archive, repo, or file system directory with Veracode Container Security.  

To patch the vulnerability, do one of the following: 

• Use Veracode SCA to scan the application code included in the container image or repo and update webp in the application as described above. 

• For a container image that contains webp as a system level package, evaluate whether upgrading to a new version of the base image will upgrade webp and fix the vulnerability.  

• In a container image that explicitly installs webp, update to the suggested fixed version. 

Note that, because Veracode Container Security uses multiple sources of vulnerability data, the CVSS score of webp vulnerabilities may differ from the severity reported in the National Vulnerability Database. This is by design, as this allows upstream distro and image maintainers to provide contextual severity of vulnerabilities based on how the libraries are used in the image. 

Alternative Method to Test for Vulnerability 

The full proof of concept (POC) code is not available on the web. The closest I’ve found to a working POC example is github.com/mistymntncop/CVE-2023-4863. In this example, the author shows how to trigger an out of bounds write which triggers an application crash. They are clear that this POC is not an “exploit” because it does not result in Code Execution. Therefore, we can only consider the Denial-of-Service part of this webp vulnerability public at this moment. Please be aware that using the crafted file will not crash all systems so the absence of a crash does not indicate the system is safe, therefore the system in question may still be exploitable. This is why in many cases the best detection method is to use SCA and Container scanning to find the presence of the vulnerable package.

How it Impacts Organizations (What it Does) 

Webp is used in many software that we rely on. The most popular examples are browsers such as Chrome, Firefox and Edge, but the vulnerability spans way beyond this scope. For example the Electron JavaScript framework. This is a very popular framework for creating web-apps and cross-platform desktops apps but internally relies on Chromium for rendering (Note that Chromium is the open source version of Google Chrome). Some popular messaging software that relies on this Electron framework is Slack and Discord. If a user sent another user a crafted webp file in one of these Electron apps, theoretically code execution is possible. Since version 20 of Electron, the Chromium process is sandboxed by default. Therefore, the code would be run in a restricted  environment, which should remove the risk of sensitive system calls. None-the-less, Electron patched Chromium in all the supported versions (22.3.24, 24.8.3, 25.8.1, 26.2.1, and 27.0.0-beta.2). Another example of a popular library which includes a compiled webp is the Python Pillow library, which has been fixed in version 10.0.1. Note that this webp process is not sandboxed, therefore the risk of code execution is higher than Electron. 

The History of the Webp Vulnerability CVE-2023-4863

The first CVE for this webp vulnerability was disclosed in CVE-2023-41061, but note how the description does not mention the root of the issue anywhere. Then Google released CVE-2023-4863, which was the first actual mention of webp. Finally CVE-2023-5129 was released, but has since been rejected. The original description of CVE-2023-5129 was:  

“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.” 

In comparison to the Chrome CVE (CVE-2023-4863) which only briefly mentions webp: 

"Heap buffer overflow in libwebp in Google Chrome prior to 116.0.5845.187 and libwebp 1.3.2 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)"

CVE-2023-5129 was rejected on 9/27/23 noting that it’s a duplicate of CVE-2023-4863. I don’t believe that this was a right call, as  CVE-2023-4863 is described as a Chrome bug. This is now causing confusion in the security community due to the difference in scores and unclear description as to what the root of the vulnerabilily is. The Chrome CVE was scored as 8.8, while the rejected webp CVE was scored as a 10. One option as to why the scores differ is that Chrome implemented webp in a sandboxed environment, which makes Code Execution harder to pull off. This is the most likely explanation as to why the scores differ. If one integrates webp itself in an application, its up to the developer to use it in a sandboxed environment which should mitigate worst case code execution. If an attacker does execute code via this webp bug in a sandboxed environment, calls to external resources on the system are limited. At Veracode, we will continue to use CVE-2023-4863 as the vulnerability identifier for all libraries that include webp.  

The vulnerability was first disclosed by Citizen Lab, titled “BLASTPASS”. Check out the link to their blog here. To summarize, Citizen Lab disclosed an active “zero click” campaign against Apple users initiated by the NSO spyware company. The attack involved sending a text message to a user containing a “PassKit” attachment. An Apple device simply receiving this iMessage containing a crafted webp file results in Code Execution, without any interaction from the user.  

The vulnerability was introduced in version 0.5.0 via this commit, which improved the lossless Huffman encoding. Huffman coding is a data compression algorithm where the frequency of symbols (different bytes) is estimated in a tree data structure. This allows for various data formats (such as images) to be compressed in a way where the resulting image after encoding has the same quality as the original. This is called “lossless” encoding. In comparison to other image formats, such as jpeg which is considered a “lossy” compression algorithm, where data is lost during the encoding process.