Microsoft recently released a report about a ChromeOS remote memory corruption vulnerability. The issue has already been fixed. In fact, it was reported to Google in April. The fix was applied shortly after, and released on June 15. The resulting deep-dive from Microsoft is a fascinating look at how one technology giant addresses another’s bugs and issues.
A critical issue
The problem, known as CVE-2022-2587 on the Common Vulnerabilities and Exposures (CVE) list, caused big headaches for Chrome. It also racked up a Common Vulnerability Score (CVSS) of 9.8, which results in it being tagged as “Critical”. As per the description:
Out of bounds write in Chrome OS Audio Server in Google Chrome on Chrome OS prior to 102.0.5005.125 allowed a remote attacker to potentially exploit heap corruption via crafted audio metadata.
This is a memory corruption vulnerability in a ChromeOS component. As per the Microsoft report, it can be triggered remotely. Attack options are varied, ranging from denial of service attacks to remote code execution. Manipulating audio metadata and baiting potential victims with songs played in browsers or paired Bluetooth devices could be enough to set the ball rolling.
How was this possible? Let’s take a look.
The realm of common ChromeOS problems
Microsoft points out that ChromeOS vulnerabilities typically land in one of three categories:
-
ChromeOS specific logic vulnerabilities.
-
ChromeOS specific memory corruption vulnerabilities.
-
Broad threats like browser vulnerabilities.
This one falls under category number 2. The problem stems from the use of something called D-Bus.org.chromium.cras, a D-Bus service related to audio which gives users a way to channel audio to new devices. These devices might take the form of headsets, speakers, anything as long as it’s audio-centric.
The strange world of Strcpy
While looking at the ways audio could be routed to new peripherals, Microsoft observed a handling function called SetPlayerIdentity. Where this goes wrong is one of the functions involved makes a call to something called strcpy. Sadly for strcpy, it’s been known as something potentially dangerous which should be avoided when possible for many years.
Strcpy doesn’t know how big a destination buffer is going to be. Programming accidents may result in the buffer being overrun. This could lead to otherwise innocent crashes or actual exploitation by people with bad intentions.
In this case, it resulted in a vulnerability triggered using a single command line sent-argument containing more than 128 bytes. That’s bad, but this requires developer mode. As the majority of Chrome users will never touch that mode, Microsoft researchers needed a way to make this happen without it.
Remotely exploiting your way to a fix
Going back to the SetPlayerIdentity handling function, researchers made their breakthrough. Changes to audio metadata could trigger the vulnerability in just the way they were looking for:
-
From the browser: The browser’s media component invokes the function when metadata is changed, such as when playing a new song in the browser.
-
From Bluetooth: The media session service in the operating system invokes the function when a song’s metadata changes, which can happen when playing a new song from a paired Bluetooth device.
It took Google less than a week to have code ready and made available to users. As a result, ChromeOS users have been happily connecting new audio devices for some time now without having a sound-related mishap of the exploitation kind.
