Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Whose CVE Is It Anyway?

The latest vulnerability causing headaches across the world is CVE-2023-4863, issued by Google Chrome and described as “Heap buffer overflow in WebP in Google Chrome prior to 116.0.5845.187 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page”. This same CVE is cited by a number of other vendors as they are impacted as well. But, is this really a Google Chrome vulnerability?

The fix for this issue is not actually part of Chrome or even Chromium, but rather the libwebp library, which is used by Chromium, and a number of other projects. The library is maintained by the WebM Project, which is a joint effort between Google and a number of other companies. Firefox, for example, uses also uses libwebp, and is impacted by this vulnerability - though they don’t mention Chrome in their advisory, but they do mention Chrome’s CVE.

flowchart LR
    B[ libwebp]
    B-->C[ Chromium]
    C-->D( Chrome)
    C-->E(Electron)
    B-->F( Firefox)
    E-->G(Visual Studio Code)
    E-->H(Signal)
    E-->I( Slack)
    C-->J[ Edge]
    B-->K[ Android]
    C-->L[Brave]

Every product mentioned in that chart (and many others) have found themselves impacted to some degree by this vulnerability in libwebp, yet the defining CVE for the vulnerability was issued by the Google Chrome CNA as a Chrome vulnerability, instead of targetting either of the upstream sources. There are countless applications that use Electron, or Chromium, or libwebp, and they are all impacted by this vulnerability, yet the CVE is tied to Chrome. Some vendors have opted to cite the Chrome CVE, some have issued updates without actually explaining what they are patching, and some may end up issuing their own CVEs. This is less than ideal.

The CVE system is a wonder in many ways, both good and bad, while it’s easy to bash the system for its flaws, it has proven useful and sustainable - something that isn’t common in this field. That said, it does certainly have flaws, and the CNAs that issue the CVEs are not always consistent in their approach. In this case, the Chrome CNA has opted to issue a CVE for a vulnerability in a library that is semi-independent of Chrome, and is used by a number of other products.

When talking about this CVE, it could mean Chrome, the layers upstream of Chrome, or the things that are downstream of the upstream components. If asked if you had patched for this vulnerability, would it even be possible to give a confident answer? If you updated Slack, do you know if it was patched? With the mass proliferation of Electron, it’s likely that you have a number of applications that are impacted, and you may not even know it. Would you know from the CVE description that Android was impacted? If you had to explain to a customer that you’ve patched for this, do you reference this CVE, or that you’ve patched for the libwebp vulnerability? If you reference the CVE, you’ll likely confuse them (they’ll undoubtedly what Chrome has to do with it) - if you reference the library, they may not know what you are talking about.

The best advice at the moment, is just update everything.

Adam Caudill