Critical vulnerability in LibWebP exploited in the wild
Recently a new vulnerability was discovered in libwebp library which parses WebP image format. This vulnerability is exploited in the wild by NSO group’s Pegasus spyware.
The vulnerability discovered in the libwebp library extends beyond browsers such as Chrome, Edge and Chromium-based applications because libwebp is in widespread use by numerous operating systems and popular application frameworks that render .webp images.
As a result, the libwebp vulnerability impacts general-purpose software like Pillow and FFMPEG.
It's important to note that some of these applications and software components can be bundled as dependencies to containers and possibly direct or in-direct dependencies to your software.
CVE-2023-4863 CVSS: 8.8: 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-41064 CVSS: 7.8: Buffer overflow vulnerability in iOS 16.6.1 and iPadOS 16.6.1, macOS Monterey 12.6.9, macOS Ventura 13.5.2, iOS 15.7.9 and iPadOS 15.7.9, macOS Big Sur 11.7.10. Processing a maliciously crafted image may lead to arbitrary code execution.
CVE-2023-41061 CVSS: 7.8: This issue is fixed in watchOS 9.6.2, iOS 16.6.1 and iPadOS 16.6.1. A maliciously crafted attachment may result in arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.
Note that CVE-2023-5129, submitted by Google Chrome and initially ranked with the maximum vulnerability score of 10, was later rejected due to duplication.
Am I affected?
Libwebp from 0.5.0 up to and including 1.3.1 are affected. You must ensure that you have version 1.3.2 or newer to remediate the vulnerability.
To know whether you’re affected you need to understand all the building blocks of your software. A Software Bill of Materials (SBOM) is a comprehensive inventory, a detailed list of ingredients that make up software components, including the usage and version of libwebp. Because SBOM contains every building block of the software, it means that it contains much more than the direct dependencies of your software. Before you rush into fixing the vulnerability, first, ensure it is executed. If the vulnerable library exists but isn't running, it doesn't pose a security gap.
Determining if libwebp is running in your environment requires a runtime SBOM tool which can detect which code is active. It can identify if the vulnerable library was loaded into memory, if the vulnerable function [.code-span]ReadHuffmanCodes[.code-span] was loaded into memory, and if that function was executed. One of the main goals of runtime SBOM is to reduce false positives and alerts, enabling you to focus on fixing only the most relevant vulnerabilities.
Using Kodem you can detect all your dependencies and know which service uses a vulnerable libwebp and whether it is loaded into memory and executed.
After detecting the vulnerable packages, we face the important question of how they should be fixed? Using Kodem’s runtime application context we can not only understand that we have a vulnerable package but also determine which resource is using it, and which command downloaded the library as part of the docker build.
The Kodem platform is differentiated in the crowded landscape of application security because of its focus on runtime intelligence and streamlining remediation. Scan your infrastructure today to discover if you’re really affected by Libwebp vulnerabilities