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

Related Posts

  • Ruby + GCM Nonce Reuse: When your language sets you up to fail…

    A couple hours ago, Mike Santillana posted to oss-security about a rather interesting find in Ruby’s OpenSSL library; in this case, the flaw is subtle – so much so that it’s unlikely that anyone would notice it, and it’s a matter of a seemingly insignificant choice that determines if your code is affected. When performing AES-GCM encryption, if you set the key first, then the IV, and you are fine – set the IV first, you’re in trouble.

  • Gpg4win & IDEA

    Huge PGP files, an ancient version of PGP, and errors every time they tried to decrypt a file – that was my completely unexpected challenge on Friday. Dealing with file processing issues really isn’t part of my job description, but I’m the closest thing my company has to an expert when it comes to encryption, so the task fell to me. After looking at the options and issues to get the server upgraded to a non-stone-age version of the PGP software, the easiest answer looked like decrypting the files with GPG – it wasn’t as easy as expected, but I did get some useful information that may help others.

  • The Pressure to Be Great

    I’m a developer, and I love what I do, it’s a great industry, and a very exciting field to be in. If you read my blog often, you’ll see I take every opportunity to mention how great this line of work can be, today I offer a somewhat different, less sugar-coated view. The Pressure There is a constant pressure on developers to be better, to do more, to produce more, sometimes more than is possible.