Guidance on the Recent Critical libwebp and libvpx Vulnerabilities
Background
Over the past few weeks, Google released updates to Google Chrome, which included fixes for CVE-2023-4863 and CVE-2023-5217. Both vulnerabilities were discovered as zero-day vulnerabilities exploited in the wild, and the CVE entries were updated to broaden the scope from just Google Chrome to their underlying libraries — libwebp and libvpx. Both CVEs appear in the CISA’s Known Exploited Vulnerabilities Catalog.
In this blog post, we share the details of both vulnerabilities and provide recommendations for how to detect vulnerable applications in your network. As these vulnerabilities are undergoing continued research, this post may be updated in the future with further insights and guidance.
CVE-2023-4863 — libwebp
This vulnerability was reported by Apple's Security Engineering and Architecture (SEAR) team and The Citizen Lab. Based on that report, researchers have correlated this vulnerability with the BLASTPASS attack — an NSO Group zero-click zero-day exploit for iPhones.
The vulnerability itself is a heap overflow in libwebp, which lies in the process of decoding webp images in the lossless format. Ben Hawkes wrote a very detailed technical analysis of the vulnerability.
Libwebp is a library developed by Google to encode and decode images in the WebP format (also developed by Google). The vulnerability lies in the library’s parsing of images with lossless compression, which uses Huffman tables. Basically, an attacker can manipulate the tables to cause the library to allocate less memory for the tables than their actual size; this results in a heap overflow and an out-of-bounds write.
There are many ways and configurations to achieve such results, so there’s no one proof of concept (PoC) to rule them all, but you can check @mistymntncop’s PoC for an example of exploitation implementation.
CVE-2023-5217 — libvpx
This vulnerability was discovered by Clément Lecigne of Google's Threat Analysis Group. This vulnerability was also used by a commercial surveillance vendor.
Libvpx is also part of the WebP project. Specifically, the library deals with the VP8 and VP9 formats for video encoding and decoding. There are fewer details surrounding this vulnerability, but it’s known that it is also a heap corruption vulnerability.
What’s vulnerable?
Initially, only browsers were reported as vulnerable, since the vulnerabilities were in Chromium. However, since the vulnerability lies in the underlying libraries libwebp and libvpx, the scope of impact is much broader: Applications using libwebp versions 0.5.0. to 1.3.1 and applications using version of libvpx earlier than 1.13.1 are affected.
We’ve compiled a list of applications that rely on either one of the libraries, based on publicly available reports. We’ve also included programs that use the library that we detected using our Insight queries. This does not mean that they’re necessarily vulnerable.
For a program to be vulnerable it has to use the WebP lossless capability of libwebp or the V8 or V9 codecs with libvpx. Since these libraries can be used for completely different features and capabilities, the use of them does not always equate to a vulnerability.
We know that the web browsers use these capabilities, but we depend on vendor discretion to tell us whether other programs are using them. We’ve found that the following browsers and other applications use the affected libraries:
- Fedora (37–39)
- Debian (10–12)
- Google Chrome
- Firefox
- Microsoft Edge
- Opera
- Tor
- Brave
- Vivaldi
- Telegram
- Discord
- 1Password
- Electron
- GIMP
- Slack
- LibreOffice
- Skype
- Grafana
- KeePassXC
- VLC
Additionally, an anonymous person analyzed Ubuntu’s package repositories and uploaded a list of all packages that rely on libvpx7.
Vulnerability exposure — OSquery
Since the library can be found in many different places, and it is up to software vendors to update their products, it is crucial to detect the vulnerability scope and exposure rate of machines in your network. We’ve developed several OSquery queries to help with that. Akamai Guardicore Segmentation customers can use the Insight feature to run those queries across their networks.
libweb and libvpx loaded in memory
Since the libraries can come with any application, locating them on the hard drive is not feasible. Instead, we can check the loaded modules (DLL or SO files) in each running process using the OSquery table process_memory_map and try to obtain the version using the file table.
Since version metadata is added during the compilation process, it will not necessarily be available, as the library can be compiled without it. Even when the version metadata is available, it might not be accurate, as vendors can attach their own software versioning instead. User discretion is advised to avoid false positives or true negatives.
SELECT DISTINCT
procs.name AS process_name,
pmm.path AS lib_path,
file.file_version,
CASE
WHEN file_version = '' THEN 'unknown version, potentially vulnerable'
WHEN pmm.path LIKE '%libwebp%' AND file_version < '1.3.2' THEN 'vulnerable version'
WHEN pmm.path LIKE '%libwebp%' AND file_version >= '1.3.2' THEN 'not vulnerable version'
WHEN pmm.path LIKE '%libvpx%' AND file_version <= '1.13.1' THEN 'vulnerable version'
WHEN pmm.path LIKE '%libvpx%' AND file_version > '1.13.1' THEN 'not vulnerable version'
ELSE 'unknown version, potentially vulnerable'
END is_vulnerable
FROM process_memory_map AS pmm
JOIN processes AS procs USING(pid)
JOIN FILE ON file.path = pmm.path
WHERE pmm.path LIKE '%libwebp%' OR pmm.path LIKE '%libvpx%'
Locating web browsers
We’ve included a query to detect installed browsers, since the initial report for the CVEs and the use case came from Chromium. This query can help locate assets in the network that run browsers and may require further investigation. You can then comapre the installed version with the list of vulnerable browser versions in the National Vulnerability Database (NVD).
SELECT name, version FROM programs
WHERE LOWER(name) LIKE "%chrome%"
OR LOWER(name) LIKE "%firefox%"
OR LOWER(name) LIKE "%microsoft edge%"
OR LOWER(name) LIKE "%thunderbird%"
OR LOWER(name) LIKE "%brave%"
OR LOWER(name) LIKE "%opera%"
Locating installed programs
To check if one of the programs from the list above is installed, use the following query; just replace <program_name> with the actual program name.
SELECT name, version FROM programs
WHERE name LIKE "%<program_name>%"
Mitigation
Mapping vulnerable applications and assets
Using the compiled list of applications and the Osquery queries provided in this blog post, you can map the potentially vulnerable applications in your network and derive a list of potentially vulnerable assets.
Akamai Hunt customers received a report detailing their environments’ exposure to the vulnerability. The Hunt reports were based on queries similar to the ones in this blog post, and were sent within a few hours after the start of the incident. The queries detected thousands of vulnerable assets across the globe.
Patching
There are many parameters that are taken into account when trying to assess if an application is vulnerable: What version of libwebp or libvpx does it load? Does the application make use of WebP lossless compression or VP8/VP9 codecs? Because of the various possible combinations, many applications are susceptible to exploitation, and the impact can be vast.
Unfortunately, there is no one patch that mitigates this vulnerability. Patching also relies on software vendors to release the relevant patches for their programs, which might take a while. Organizations need to assess over time which workloads are vulnerable and remain unpatched.
Threat alert sensitivity
Since patches for all affected programs are not necessarily available yet, it might be prudent to increase your alert sensitivity on the workloads that might be potentially vulnerable and unpatched. That way, even if the vulnerability is exploited and undetected, you might still have some awareness of its aftereffects.
However, this can increase alert fatigue. As a result, we recommend adjusting the alert sensitivity according to the affected workload’s importance to the network or its impact.
Summary
In this blog post, we reviewed the available information about the critical vulnerabilities in libwebp and libvpx, which have been exploited in the wild.
For defenders, the critical move is to determine the vulnerability of the workloads in their network. We’ve attempted to help by providing OSquery queries to detect programs that use the libraries. We’ve also discussed what to do to mitigate some of the risk (i.e., adjust your threat alert sensitivity) when patching is unavailable.
This blog post provides an overview of our current understanding and our recommendations given the information available. Our review is ongoing and any information herein is subject to change. You can also visit our Twitter account for real-time updates.
