{"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\n Therefore, the vulnerability could be triggered using a single command line by sending the identity<\/em> user-controlled D-Bus argument with more than 128 bytes, as displayed in our example code below:<\/p>\n\n\n\n As most users don\u2019t need to enable ChromeOS\u2019s developer mode and, thus, can\u2019t use the dbus-send<\/em> utility, our next task was to find a way to trigger the bug without using developer mode.<\/p>\n\n\n\n Thinking we spotted a local memory corruption issue, we wanted to better understand how to trigger the bug. Since the involved functions exclusively get triggered from D-Bus, we looked for functions that trigger the SetPlayerIdentity<\/em> D-Bus method\u2014if the arguments to those don\u2019t have bounds checks, then those functions could be used to trigger the vulnerability.<\/p>\n\n\n\n Examining the open-source ChromiumOS repositories found that the CRAS audio client invokes the SetPlayerIdentity <\/em>method (and exports a function with the same name). In turn, it\u2019s called by the CRAS audio handler component\u2019s method MediaSessionMetadataChanged<\/em>, which extracts the identity<\/em> from a metadata structure representing a song’s title:<\/p>\n\n\n\n At this point, it was clear that the vulnerability could be triggered via changes to the audio metadata. Looking for MediaSessionMetadataChanged<\/em> invocations revealed two interesting cases that could both be triggered remotely:<\/p>\n\n\n\n We reported the vulnerability to Google in April 2022 as a part of the Chromium bug tracking system and were assigned Issue 1320917<\/a>, which immediately got assigned as a priority 1 security bug. In parallel, we tracked the issue internally in Microsoft Security Vulnerability Research<\/a> (MSVR), while using OSINT<\/a> to look for indications of that vulnerability being used in the wild. We did not find any indications of in-the-wild exploitation.<\/p>\n\n\n\n The impact of heap-based buffer overflow ranges from simple DoS to full-fledged RCE. Although it\u2019s possible to allocate and free chunks through media metadata manipulation, performing the precise heap-grooming<\/a> is not trivial in this case and attackers would need to chain the exploit with other vulnerabilities to successfully execute any arbitrary code. Given the potential impact of the vulnerability, coupled with the fact that it could be remotely triggered, it\u2019s a security risk that justifies the bug priority and how fast the fix was issued.<\/p>\n\n\n\n We were impressed with the speed of the fix<\/a> and the effectiveness of the overall process. 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.<\/p>\n\n\n\n As the threat and computing landscape continues to evolve, Microsoft strives to continuously improve security for all through research-driven protections and collaboration with customers, partners, and industry experts, regardless of the device or platform in use.<\/p>\n\n\n\n To defend against the evolving threat landscape, organizations must closely monitor all devices and operating systems across platforms, including unmanaged devices. Unmanaged devices are sometimes ignored or missed by security teams at join time, making them attractive targets for compromising, quietly performing lateral movements, jumping network boundaries, and achieving persistence for the sake of launching broader attacks. Microsoft Defender for Endpoint’s device discovery capabilities<\/a> help organizations find certain unmanaged devices, including those running ChromeOS, and can detect if they are being operated by attackers when they start performing network interactions with servers and other managed devices.<\/p>\n\n\n\n Microsoft security researchers continually work to discover new vulnerabilities and threats, turning knowledge of a variety of wide-reaching issues into improved solutions that protect users and organizations across platforms every single day. This case displays how vulnerability disclosures and threat intelligence sharing are essential to effectively mitigate issues and protect users against present and future threats. Moreover, by expanding upon our prior research, we can also continue to make positive contributions to the overall security of devices worldwide, even on platforms we currently don\u2019t directly support.<\/p>\n\n\n\n Jonathan Bar Or<\/strong><\/p>\n\n\n\n Microsoft 365 Defender Research Team<\/p>\n","protected":false},"excerpt":{"rendered":" Microsoft discovered a memory corruption vulnerability in a ChromeOS component that could have been triggered remotely, allowing attackers to perform either a denial-of-service (DoS) or, in extreme cases, remote code execution (RCE).<\/p>\n","protected":false},"author":153,"featured_media":120401,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ms_queue_id":[],"ep_exclude_from_search":false,"_classifai_error":"","_classifai_text_to_speech_error":"","footnotes":""},"content-type":[3663],"topic":[3687],"products":[],"threat-intelligence":[3739],"tags":[3917,3782],"coauthors":[3380],"class_list":["post-120374","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","content-type-research","topic-threat-intelligence","threat-intelligence-vulnerabilities-and-exploits","tag-adversary-in-the-middle","tag-linux"],"yoast_head":"\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
dbus-send --system --dest=org.chromium.cras --type=method_call --print-reply \/org\/chromium\/cras org.chromium.cras.Control.SetPlayerIdentity string:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA<\/pre>\n\n\n\n
Triggering the bug remotely<\/h2>\n\n\n\n
Implications and reporting<\/h2>\n\n\n\n
Improving security for all through research and threat intelligence sharing<\/h2>\n\n\n\n