Microsoft Finds Critical Hole In OS That For Once Isn’t Windows
Microsoft has described a severe ChromeOS security vulnerability that one of its researchers reported to Google in late April.
The bug was promptly fixed and, about a month later, merged in ChromeOS code then released on June 15, 2022 and detailed by Redmond in a report released on Friday.
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.”
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. ®
READ MORE HERE
