Microsoft finds critical hole in operating system that for once isn't Windows
Oh wow, get a load of Google using strcpy() all wrong – strcpy! Haha, you'll never ever catch us doing that
Microsoft has described a severe ChromeOS security vulnerability that one of its researchers reported to Google in late April.
Microsoft's write-up is noteworthy both for the severity (9.8 out of 10) of the bug and for flipping of the script – it has tended to be Google, particularly its Project Zero group, that calls attention to bugs in Microsoft software.
At least as far back as 2010, Google security researchers made a habit of disclosing bugs in software from Microsoft and other vendors after typically 90 days – even if a patch had not been released – in the interest of forcing companies to respond to security flaws more quickly.
Microsoft has chided Google about this several times over the years, though as early as 2011, Redmond showed itself willing to adapt with a revised security disclosure policy that arrived with word of Chrome vulnerabilities – albeit months after Google had fixed them.
Microsoft's disclosure of the ChromeOS critical flaw isn't a zero-day since Google made the necessary repairs. But it allows the Windows giant to magnanimously point out the problems in a competitor's hardened code and to pat Google on the back for its rapid repairs.
A critical issue
The ChromeOS memory corruption vulnerability – CVE-2022-2587 – was particularly severe. As Jonathan Bar Or, a member of the Microsoft 365 Defender research team, explains in his post, the problem follows from the use of D-Bus, an Inter-Process-Communication (IPC) mechanism used in Linux.
A D-Bus service called
org.chromium.cras (for ChromiumOS Audio Server) provides a way to route audio to newly added peripherals like USB speakers and Bluetooth headsets. The service includes a function called
SetPlayerIdentity, which accepts a string argument called identity as its input. And the function's C code calls out to
strcpy in the standard library. Yes,
strcpy, which is a dangerous function.
"To the experienced security engineer, the mention of the
strcpy function immediately raises red flags," explains Jonathan Bar Or. "The
strcpy function is known to cause various memory corruption vulnerabilities since it doesn’t perform any bounds check and is therefore considered unsafe.
"As there are no bounds checks on the user-supplied identity argument before invoking
strcpy (besides the default message length limitations for D-Bus messages), we were confident we could trigger a heap-based buffer overflow, therefore triggering a memory corruption vulnerability."
- Warning over Java libraries and deserialization security weaknesses
- Two years on, Apple iOS VPNs still leak IP addresses
- Google, Apple squash exploitable browser bugs
- The truth about that draft law banning Uncle Sam buying insecure software
From the command line, a heap-based buffer overflow could be achieved simply by passing a 200-character string to the
dbus-send utility. And with a bit more effort, it was determined that song metadata, passed to the CRAS audio handler component via the
MediaSessionMetadataChanged method, could trigger the bug remotely via browser or Bluetooth.
Bar Or allows that while turning this bug into a remote code execution exploit would require heap grooming and chaining with other vulnerabilities, it's dangerous enough to justify Google's rapid response.
"We were impressed with the speed of the fix and the effectiveness of the overall process," he said.
"Within less than a week, the code was committed and, after several merges, made generally available to users. We thank the Google team and the Chromium community for their efforts in addressing the issue."
Bar Or already received thanks from Google's Vulnerability Rewards Program, which in June awarded him $25,000 for the responsible disclosure of the bug. ®