Libwebp is a popular open-source library developed by Google for encoding and decoding images in the WebP format. It is widely used in applications like web browsers and image editing tools for better image compression and faster web performance. In this post, we're going to discuss the discovery of a use-after-free and double-free vulnerability within Libwebp, which has been assigned the CVE identifier CVE-2023-1999. We will dive into the origin of this vulnerability, walk through the code snippet that triggers it, and detail the potential exploit scenarios.

Libwebp Vulnerability Origins

This vulnerability exists due to a coding error in the ApplyFiltersAndEncode() function, which is responsible for applying filters and encoding data within Libwebp. The issue arises when the function loops through freeing the best.bw buffer while also assigning the best pointer to the trial pointer. Consequently, an out-of-memory (OOM) error, when encountered in the second loop, results in a double-free scenario.

Code Snippet

The problematic code snippet from the Libwebp library, related to the ApplyFiltersAndEncode() function, can be found below:

  // Loop to free best.bw and assign best = trial.
  if (DoFiltersApply(&best, &bw, &bw_hdr, trial, &rw)) {
    WebPConfigCopy(config, &trial->config_);
    ByteWriterFree(&best.bw);
    best = *trial;  // Assignment to trial pointer.
  }

  // Second loop that causes OOM error and double-free issue.
  while (!ok && TryLaterFilterLess(&best)) {
    ok = DoFiltersApply(&best, &bw, &bw_hdr, trial, &rw);
  }
  if (!ok) {  // Out-of-memory error handling.
    return ; // OOM error in VP8 encoder.
  }

When the ApplyFiltersAndEncode() function is executed, the first loop frees the best.bw buffer and assigns best to point to the trial buffer. In the second loop, if an OOM error occurs in the VP8 encoder, the ok flag will be set to , resulting in a return from the function. However, the best pointer still points to the trial buffer, causing the AddressSanitizer to attempt to free the trial buffer again during the cleanup phase, hence triggering a double-free scenario.

Exploit Details

An attacker can exploit this vulnerability by crafting a malicious image that triggers the code path containing the double-free issue in the target application using the Libwebp library. The target application may crash or become unresponsive due to the double-free condition, possibly leading to denial of service (DoS) attacks.

Furthermore, if an attacker can successfully control the content placed at the freed trial buffer's address, they might be able to execute arbitrary code with the same privileges as the target application, potentially leading to code execution, privilege escalation, or information disclosure.

Original References

1. Libwebp GitHub Repository: https://github.com/webmproject/libwebp
2. WebP File Format Specification: https://developers.google.com/speed/webp/docs/riff_container
3. CVE-2023-1999 NIST National Vulnerability Database Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-1999

Conclusion

The use-after-free and double-free vulnerability in the Libwebp library, identified as CVE-2023-1999, poses a security risk to applications that rely on this library to encode and decode WebP images. Developers and users should ensure that they have updated their copies of Libwebp to a version that addresses this issue, and they should remain vigilant for any other potential vulnerabilities within the library.

In this post, we have unraveled the origin of this vulnerability, demonstrated the code snippet that triggers it, and discussed the potential exploit scenarios. Developers should be aware of such vulnerabilities and follow best coding practices to prevent similar issues in the future. By staying informed and proactive, we can help protect our software applications and end users from potential security threats.

Timeline

Published on: 06/20/2023 12:15:09 UTC
Last modified on: 09/17/2023 09:15:12 UTC