{"id":120374,"date":"2022-08-19T14:38:06","date_gmt":"2022-08-19T21:38:06","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/?p=120374"},"modified":"2023-10-13T07:16:37","modified_gmt":"2023-10-13T14:16:37","slug":"uncovering-a-chromeos-remote-memory-corruption-vulnerability","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2022\/08\/19\/uncovering-a-chromeos-remote-memory-corruption-vulnerability\/","title":{"rendered":"Uncovering a ChromeOS remote memory corruption vulnerability"},"content":{"rendered":"\n
Microsoft discovered a memory corruption vulnerability in a ChromeOS component that can be triggered remotely, allowing attackers to perform either a denial-of-service (DoS) or, in extreme cases, remote code execution (RCE). Following our D-Bus blog post<\/a> that focused on Linux, we searched for similar D-Bus patterns on other platforms by auditing D-Bus services and their handler code. After locating a local memory corruption issue, we discovered the vulnerability could be remotely triggered by manipulating audio metadata. Attackers could have lured users into meeting these conditions, such as by simply playing a new song in a browser or from a paired Bluetooth device, or leveraged adversary-in-the-middle (AiTM) capabilities to exploit the vulnerability remotely.<\/p>\n\n\n\n After carefully reviewing the implications, a Microsoft security researcher shared the vulnerability with Google in April 2022 and also reported it with the Chromium bug tracking system<\/a>. Fixes for the vulnerability, which is assigned as CVE-2022-2587<\/a> and has a Common Vulnerability Scoring System (CVSS<\/a>) score of 9.8 (classifying the vulnerability as critical), were quickly released and have been successfully deployed to end users<\/a>. We\u2019d like to thank the Google team and the Chromium community for their professional resolution and collaborative efforts.<\/p>\n\n\n\n This research coupled with the recent release of ChromeOS Flex<\/a>, which can convert various legacy PCs and Macs into Chromebooks, emphasizes the importance of analyzing and monitoring security for devices running ChromeOS. Moreover, as even the most hardened operating systems might contain security bugs, we emphasize the need for strong monitoring of all cross-platform devices and operating systems. The best approach for protecting unmanaged devices is by using Microsoft Defender for Endpoint’s device discovery capabilities<\/a> to monitor suspicious traffic and help detect attacker activities on such devices.<\/p>\n\n\n\n In this blog post, we share some information about the vulnerability and examine how it could be triggered as well as the possible implications. Displaying how our cross-domain expertise helps us uncover new and unknown threats in the effort to continually improve security for all, we also share details from our research with the larger security community to emphasize the importance of collaboration to secure platforms and devices.<\/p>\n\n\n\n One well-known operating system that uses D-Bus is ChromeOS. ChromeOS is a Google-proprietary Linux-based operating system that runs on Chromebooks, Chromeboxes, Chromebits and Chromebases. ChromeOS is a closed-source system with open-source components that are derived from ChromiumOS, and the operating system uses Google\u2019s own Chrome browser as its principal user interface.<\/p>\n\n\n\n In terms of security, ChromeOS is well hardened<\/a>; some of the security features on ChromeOS include:<\/p>\n\n\n\n As with other modern browsers, exploiting ChromeOS usually requires chaining vulnerabilities together. Due to hardening measures in ChromeOS, discovering vulnerabilities became a specific niche and, therefore, the number of public vulnerabilities is quite low compared to other operating systems. ChromeOS vulnerabilities generally fall into one of three different classes:<\/p>\n\n\n\n In this case, the discovered vulnerability falls under the second class, ChromeOS-specific memory-corruption vulnerabilities.<\/p>\n\n\n\n Having discussed and extensively researched D-Bus<\/a>, we continued this analysis by enumerating the D-Bus services offered on ChromeOS. In general, D-Bus is an Inter-Process-Communication (IPC) mechanism that\u2019s popular on desktop platforms, specifically Linux.<\/p>\n\n\n\n ChromeOS\u2019s developer mode<\/a> offers the dbus-send<\/em> utility to send messages over D-bus. As there are many D-Bus services offered on ChromeOS (usually identified by the \u201corg.chromium<\/em>\u201d prefix), we automated the process and used the dbus-send<\/em> utility to fetch the full tree of services and their exported methods and signals.<\/p>\n\n\n\n Because most D-Bus services support the org.freedesktop.DBus.Introspectable<\/em> interface, it\u2019s possible to dynamically fetch exported methods and signals without reading the source code or reverse-engineering the binaries.<\/p>\n\n\n\n Fetching all the exported service names can be performed using the following command:<\/p>\n\n\n\n Using org.chromium.ResourceManager<\/em> as an example, each service can then be enumerated for its declared methods and signals via the following command:<\/p>\n\n\n\n Considering that the more input a method receives, the higher the probability of finding a security issue, we then focused on methods that export arbitrarily large inputs, such as strings or arrays. It wasn\u2019t long before we found an interesting service: org.chromium.cras<\/em>.<\/p>\n\n\n\n The org.chromium.cras<\/em> D-Bus name is owned by CRAS (ChromiumOS Audio Server), which has a well-documented architecture<\/a> under the ChromiumOS wiki pages. In essence, CRAS is a server that resides between the operating system and ALSA (Advanced Linux Sound Architecture) as a means of routing audio to newly attached audio-supporting peripherals, like USB speakers and Bluetooth headsets.<\/p>\n\n\n\n Reviewing the exported methods uncovered one method with a particularly interesting handling function: SetPlayerIdentity<\/em>, which gets one string (an argument called identity<\/em>) as an input. Since ChromiumOS is open-sourced, tracking the calls is straightforward:<\/p>\n\n\n\n To the experienced security engineer, the mention of the strcpy<\/em> function immediately raises red flags. The strcpy <\/em>function is known to cause various memory corruption vulnerabilities since it doesn\u2019t perform any bounds check and is therefore considered unsafe. As there are no bounds checks on the user-supplied identity<\/em> argument before invoking strcpy <\/em>(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.<\/p>\n\n\n\n Heap-based buffer overflows can be the cause of multiple vulnerabilities, most notoriously leading to arbitrary code execution through various means. This could include overriding a function callback in an allocated object or overriding chunk metadata, which can trigger other unexpected behavior during the lifetime of a program.<\/p>\n\n\n\n Checking how the player.identity<\/em> string is initialized shows that it\u2019s set in the cras_bt_player_init<\/em> function as the result of malloc(128)<\/em>, which means it\u2019s allocated on the user\u2019s heap with 128 bytes.<\/p>\n\n\n\nAn overview of ChromeOS security<\/h2>\n\n\n\n
Bug hunting<\/h2>\n\n\n\n
dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply \/org\/freedesktop\/DBus org.freedesktop.DBus.ListNames<\/pre>\n\n\n\n
dbus-send --system --dest=org.chromium.ResourceManager --type=method_call --print-reply \/org\/chromium\/ResourceManager org.freedesktop.DBus.Introspectable.Introspect<\/pre>\n\n\n\n
The vulnerability<\/h2>\n\n\n\n