CVE-2023-4863: Leverage Apiiro to determine risk from new WebP 0-day

As we’re all aware of by now, a critical security flaw has been identified in libwebp, a widely used open-source library from Google that encodes and decodes images in WebP format. CVE-2023-4863 is a 0-day vulnerability that allows for RCE and out-of-bounds write through a buffer overflow attack and is actively being exploited by malicious actors.

In this post, we’ll cover the importance of identifying where libwebp is in your applications, how to prioritize patching instances that are most risky to your business, and how Apiiro can help.

First, a bit about CVE-2023-4863

The Heap Buffer Overflow in libwebp 1.3.2. allows an attacker to perform an out-of-bounds memory write by crafting specialized .webp inputs. Depending on how input is provided to the library, this may translate to remote attackers being able to launch a DDoS or an RCE attack on systems utilizing the library. This is the case, for example, for Chrome versions using the vulnerable library.

Chromium security severity: Critical

NVD CVSS v3.1 Severity and Metrics:

• Base Score: 8.8 HIGH
• Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Impact Score: 5.9
• Exploitability Score: 2.8
• Attack Vector (AV): Network
• Attack Complexity (AC): Low
• Privileges Required (PR): None
• User Interaction (UI): Required
• Scope (S): Unchanged
• Confidentiality (C): High
• Integrity (I): High
• Availability (A): High

While the libwebp vulnerability was initially known as a Chrome zero-day exploit, its scope is far broader. Any application or software using libwebp is vulnerable to CVE-2023-4863, potentially allowing attackers to execute arbitrary code, compromise systems, or steal sensitive data. It is crucial to patch and secure systems, applications, or websites that rely on libwebp by upgrading to the fixed version to prevent potential exploitation and protect user data.

Identifying and prioritizing risky libwebp instances with Apiiro’s risk-based context

Whenever a new 0-day vulnerability is detected, you first need to determine if it’s being used in your code and where. But the real challenge is determining how to best allocate your (often limited) resources to prioritize and fix the instances in your applications that expose your business to actual risk.

Industry prioritization standards like CVSS, EPSS, KEV, and others are great first signals for prioritization, but because they lack context from your specific application architecture and business, you cannot rely on them to assess the unique risk of a vulnerability such as libwebp to your application.

Apiiro makes it easy to understand where you’re exposed to the libwebp vulnerability by detecting the use of vulnerable versions of wrappers of the libwebp library in various development technologies (including C#, Java, and Python). Then we layer in context derived from deep code analysis and runtime intelligence (agentless connections to K8s clusters). Whether you’re leveraging Apiiro’s native open source security solution or have integrated your existing SCA tool, Apiiro’s context automatically assesses the likelihood and impact of a vulnerable libwebp instance specific to your application and business.

Without having to deploy complex agents, Apiiro identifies:

• Likelihood factors such as:
  • actually being used in application code, not just declared in the pom.xml (in the case of Java) with high certainty that they are loaded to memory
  • Deployed
  • Exposed to the internet
  • In application logic (not in test logic)
  • Exposure time (how long you are vulnerable)
  • Used in an application with un-authenticated entry points (e.g. APIs)
• Impact factors such as:
  • Business Impact (repo/module containing PII/PHI/PCI data, high revenue-generating app, large volume of users, etc.)
  • Blast radius (used across shared code module)
  • Toxic combination (multiple related vulnerabilities and risky changes)

By automatically assessing and prioritizing the risk associated with libwebp vulnerabilities based on the above likelihood and impact factors, Apiiro can save you days or even weeks of triaging and prioritizing—depending on the size and complexity of your application.

If you’d like to see all instances of the libwebp vulnerability across your attack surface, simply search ‘CVE-2023-4863’ in the SCA Risks page to show all risks associated with this CVE.

Remediating what matters—fast

When assessing risky instances of the libwebp vulnerability, Apiiro provides insights, including the discovery date, version, associated dependencies, package information, and additional risk-specific information to help you understand the risk related to your specific organization.

To remediate fast, Apiiro ties each risk to the code owner, outlines remediation steps, and provides in-app actions so you can work with the appropriate developer to upgrade to a secure version fast.

Follow vulnerability exposure

To track your exposure to the libwebp vulnerability (or any vulnerability), you can use Apiiro’s Timeline pane, which captures all material code changes, code owners, when the vulnerable package or library was incorporated into your codebase, and when a vulnerability was reported so you know exactly how long your applications have been vulnerable.

Then, you can use Apiiro’s context to identify the relevant API and scan its log for malicious WebP files to discover if attack attempts have occurred. Understanding your exposure helps you make informed decisions about remediation and mitigation so you can minimize potential harm to your organization.

Preventing new risks with Apiiro’s risk-based policy engine

Common vulnerability databases have rigorous review processes to ensure accuracy and prevent false alarms, which can delay the approval and admittance of new vulnerabilities. With so much on your plate, it’s hard to keep up—especially when new critical vulnerabilities are tracked separately (in this case CVE-2023-41064, CVE-2023-4863 and CVE-2023-5129).

To be alerted when a vulnerability is upgraded in severity, you can build a workflow to create a Jira ticket:

Additionally, to ensure vulnerable libwebp instances don’t get incorporated into your codebase in the future, Apiiro’s risk-based workflow engine allows you to comment on or block impacted pull requests.

With this approach, you can ensure continuous coverage, control, and visibility throughout the lifecycle of a risk, so your application attack surface remains secure from potential vulnerabilities.

···

For AppSec practitioners, dealing with new 0-day vulnerabilities has always and will always be part of the job. But with the necessary context to accurately prioritize and the relevant insights to quickly remediate, it doesn’t have to be such a grueling exercise.

To see Apiiro’s risk-based approach in action, schedule a demo.