{"id":19899,"date":"2022-08-19T14:01:03","date_gmt":"2022-08-19T22:01:03","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2022\/08\/19\/news-13632\/"},"modified":"2022-08-19T14:01:03","modified_gmt":"2022-08-19T22:01:03","slug":"news-13632","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2022\/08\/19\/news-13632\/","title":{"rendered":"Uncovering a ChromeOS remote memory corruption vulnerability"},"content":{"rendered":"<p><strong>Credit to Author: Katie McCafferty| Date: Fri, 19 Aug 2022 21:38:06 +0000<\/strong><\/p>\n<p>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 <a href=\"https:\/\/www.microsoft.com\/security\/blog\/2022\/04\/26\/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn\/\">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<p>After carefully reviewing the implications, a Microsoft security researcher shared the vulnerability with Google in April 2022 and also reported it with the <a href=\"https:\/\/bugs.chromium.org\/p\/chromium\/issues\/detail?id=1320917\">Chromium bug tracking system<\/a>. Fixes for the vulnerability, now identified as CVE-2022-2587, were quickly released and have been <a href=\"https:\/\/chromereleases.googleblog.com\/2022\/06\/stable-channel-update-for-chromeos.html\">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<p>This research coupled with the recent release of <a href=\"https:\/\/cloud.google.com\/blog\/products\/chrome-enterprise\/chromeos-flex-ready-to-scale-to-pcs-and-macs\">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 <a href=\"https:\/\/docs.microsoft.com\/microsoft-365\/security\/defender-endpoint\/device-discovery?view=o365-worldwide\">Microsoft Defender for Endpoint&#8217;s device discovery capabilities<\/a> to monitor suspicious traffic and help detect attacker activities on such devices.<\/p>\n<p>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<h2>An overview of ChromeOS security<\/h2>\n<p>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<p>In terms of security, ChromeOS is well <a href=\"https:\/\/www.chromium.org\/chromium-os\/chromiumos-design-docs\/system-hardening\/\">hardened<\/a>; some of the security features on ChromeOS include:<\/p>\n<ul>\n<li>Hardened sandbox (called minijail)<\/li>\n<li>Verified boot<\/li>\n<li>Locked-down filesystem (mounted with <em>noexec<\/em>, <em>nosuid<\/em>, <em>nodev<\/em>) and dm-verity<\/li>\n<li>Root user restrictions (SECURE_NOROOT)<\/li>\n<li>When development mode is entered, all locally stored data is wiped<\/li>\n<\/ul>\n<p>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<ol type=\"1\">\n<li>ChromeOS-specific logic vulnerabilities<\/li>\n<li>ChromeOS-specific memory-corruption vulnerabilities<\/li>\n<li>Broader threats such as Chrome browser vulnerabilities<\/li>\n<\/ol>\n<p>In this case, the discovered vulnerability falls under the second class, ChromeOS-specific memory-corruption vulnerabilities.<\/p>\n<h2>Bug hunting<\/h2>\n<p>Having discussed and extensively <a href=\"https:\/\/www.microsoft.com\/security\/blog\/2022\/04\/26\/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn\/\">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<p>ChromeOS\u2019s <a href=\"https:\/\/chromium.googlesource.com\/chromiumos\/docs\/+\/HEAD\/developer_mode.md\">developer mode<\/a> offers the <em>dbus-send<\/em> utility to send messages over D-bus. As there are many D-Bus services offered on ChromeOS (usually identified by the \u201c<em>org.chromium<\/em>\u201d prefix), we automated the process and used the <em>dbus-send<\/em> utility to fetch the full tree of services and their exported methods and signals.<\/p>\n<p>Because most D-Bus services support the <em>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<p>Fetching all the exported service names can be performed using the following command:<\/p>\n<pre class=\"wp-block-preformatted\">dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply \/org\/freedesktop\/DBus org.freedesktop.DBus.ListNames<\/pre>\n<p>Using <em>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<pre class=\"wp-block-preformatted\">dbus-send --system --dest=org.chromium.ResourceManager --type=method_call --print-reply \/org\/chromium\/ResourceManager org.freedesktop.DBus.Introspectable.Introspect<\/pre>\n<p>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: <em>org.chromium.cras<\/em>.<\/p>\n<h2>The vulnerability<\/h2>\n<p>The <em>org.chromium.cras<\/em> D-Bus name is owned by CRAS (ChromiumOS Audio Server), which has a <a href=\"http:\/\/chromium.org\/chromium-os\/chromiumos-design-docs\/cras-chromeos-audio-server\/\">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<p>Reviewing the exported methods uncovered one method with a particularly interesting handling function: <em>SetPlayerIdentity<\/em>, which gets one string (an argument called <em>identity<\/em>) as an input. Since ChromiumOS is open-sourced, tracking the calls is straightforward:<\/p>\n<ol type=\"1\">\n<li>In <a href=\"https:\/\/chromium.googlesource.com\/chromiumos\/third_party\/adhd\/+\/ec204a352e068152de3020b9f91854996f95f217\/cras\/src\/server\/cras_dbus_control.c\"><em>cras_dbus_control.c<\/em>,<\/a> the handler function for <em>SetPlayerIdentity<\/em> is <em>handle_set_player_identity<\/em>, which extracts the <em>identity<\/em> argument from the D-Bus message and invoke the <em>cras_bt_player_update_identity<\/em> function.<\/li>\n<li>In <a href=\"https:\/\/chromium.googlesource.com\/chromiumos\/third_party\/adhd\/+\/ec204a352e068152de3020b9f91854996f95f217\/cras\/src\/server\/cras_bt_player.c\"><em>cras_bt_player.c<\/em>,<\/a> the function <em>cras_bt_player_update_identity<\/em> that was called checks that the <em>identity<\/em> input value is not null and is different than the current player <em>identity<\/em> string (saved under <em>player.identity<\/em>). If so, it copies the <em>identity<\/em> variable to <em>player.identity<\/em> using the C library function <a href=\"https:\/\/www.cplusplus.com\/reference\/cstring\/strcpy\/\"><em>strcpy<\/em><\/a>. Of note, \u201cplayer\u201d is a global variable in the <em>cras_bt_player<\/em> module and includes an <em>identity<\/em> field in it, among others.<\/li>\n<\/ol>\n<p>To the experienced security engineer, the mention of the <em>strcpy<\/em> function immediately raises red flags. The <em>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 <em>identity<\/em> argument before invoking <em>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<p>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<p>Checking how the <em>player.identity<\/em> string is initialized shows that it\u2019s set in the <em>cras_bt_player_init<\/em> function as the result of <em>malloc(128)<\/em>, which means it\u2019s allocated on the user\u2019s heap with 128 bytes.<\/p>\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"960\" height=\"499\" src=\"https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-1.-The-vulnerable-function-with-the-strcpy-invocation-in-it.png\" alt=\"Code depicting the vulnerable function with the strcpy invocation in it\" class=\"wp-image-120386\" srcset=\"https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-1.-The-vulnerable-function-with-the-strcpy-invocation-in-it.png 960w, https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-1.-The-vulnerable-function-with-the-strcpy-invocation-in-it-300x156.png 300w, https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-1.-The-vulnerable-function-with-the-strcpy-invocation-in-it-768x399.png 768w\" sizes=\"auto, (max-width: 960px) 100vw, 960px\" \/><figcaption>Figure 1. The vulnerable function with the <em>strcpy<\/em> invocation in it<\/figcaption><\/figure>\n<p>Therefore, the vulnerability could be triggered using a single command line by sending the <em>identity<\/em> user-controlled D-Bus argument with more than 128 bytes, as displayed in our example code below:<\/p>\n<pre class=\"wp-block-preformatted\">dbus-send --system --dest=org.chromium.cras --type=method_call --print-reply \/org\/chromium\/cras org.chromium.cras.Control.SetPlayerIdentity string:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA<\/pre>\n<p>As most users don\u2019t need to enable ChromeOS\u2019s developer mode and, thus, can\u2019t use the <em>dbus-send<\/em> utility, our next task was to find a way to trigger the bug without using developer mode.<\/p>\n<h2>Triggering the bug remotely<\/h2>\n<p>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 <em>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<p>Examining the open-source ChromiumOS repositories found that the CRAS audio client invokes the <em>SetPlayerIdentity <\/em>method (and exports a function with the same name). In turn, it\u2019s called by the CRAS audio handler component\u2019s method <em>MediaSessionMetadataChanged<\/em>, which extracts the <em>identity<\/em> from a metadata structure representing a song&#8217;s title:<\/p>\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" loading=\"lazy\" width=\"960\" height=\"493\" src=\"https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-2.-SetPlayerIdentity-triggered-from-metadata-changes.png\" alt=\"Code depicting SetPlayerIdentity triggered from metadata changes\" class=\"wp-image-120383\" srcset=\"https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-2.-SetPlayerIdentity-triggered-from-metadata-changes.png 960w, https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-2.-SetPlayerIdentity-triggered-from-metadata-changes-300x154.png 300w, https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-2.-SetPlayerIdentity-triggered-from-metadata-changes-768x394.png 768w\" sizes=\"auto, (max-width: 960px) 100vw, 960px\" \/><figcaption>Figure 2. SetPlayerIdentity triggered from metadata changes<\/figcaption><\/figure>\n<p>At this point, it was clear that the vulnerability could be triggered via changes to the audio metadata. Looking for <em>MediaSessionMetadataChanged<\/em> invocations revealed two interesting cases that could both be triggered remotely:<\/p>\n<ol type=\"1\">\n<li>From the browser: the browser\u2019s media component invokes the function when metadata is changed, such as when playing a new song in the browser.<\/li>\n<li>From Bluetooth: the media session service in the operating system invokes the function when a song\u2019s metadata changes, which can happen when playing a new song from a paired Bluetooth device.<\/li>\n<\/ol>\n<figure class=\"wp-block-image size-large is-resized\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-3.-Call-tree-displaying-how-browser-or-Bluetooth-media-metadata-changes-ultimately-trigger-the-vulnerable-component-776x1024.png\" alt=\"Call tree depicting how browser or bluetooth devices can trigger MediaSessionMetadataChanged, then SetPlayerIdentity to be sent over D-Bus, triggering handle_control_message, then handle_set_player_identity, and finally the vulnerable function: cras_bt_player_update_identity.\" class=\"wp-image-120380\" width=\"388\" height=\"512\" srcset=\"https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-3.-Call-tree-displaying-how-browser-or-Bluetooth-media-metadata-changes-ultimately-trigger-the-vulnerable-component-776x1024.png 776w, https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-3.-Call-tree-displaying-how-browser-or-Bluetooth-media-metadata-changes-ultimately-trigger-the-vulnerable-component-227x300.png 227w, https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-3.-Call-tree-displaying-how-browser-or-Bluetooth-media-metadata-changes-ultimately-trigger-the-vulnerable-component-768x1013.png 768w, https:\/\/www.microsoft.com\/security\/blog\/uploads\/securityprod\/2022\/08\/Figure-3.-Call-tree-displaying-how-browser-or-Bluetooth-media-metadata-changes-ultimately-trigger-the-vulnerable-component.png 960w\" sizes=\"auto, (max-width: 388px) 100vw, 388px\" \/><figcaption>Figure 3. Call tree displaying how browser or Bluetooth media metadata changes ultimately trigger the vulnerable function<\/figcaption><\/figure>\n<h2>Implications and reporting<\/h2>\n<p>We reported the vulnerability to Google in April 2022 as a part of the Chromium bug tracking system and were assigned <a href=\"https:\/\/bugs.chromium.org\/p\/chromium\/issues\/detail?id=1320917\">Issue 1320917<\/a>, which immediately got assigned as a priority 1 security bug. In parallel, we tracked the issue internally in <a href=\"https:\/\/www.microsoft.com\/msrc\/msvr\">Microsoft Security Vulnerability Research<\/a>&nbsp;(MSVR), while using <a href=\"https:\/\/en.wikipedia.org\/wiki\/Open-source_intelligence\">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<p>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 <a href=\"https:\/\/en.wikipedia.org\/wiki\/Heap_feng_shui\">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&nbsp;and how fast the fix was issued.<\/p>\n<p>We were impressed with the speed of <a href=\"https:\/\/chromium.googlesource.com\/chromiumos\/third_party\/adhd\/+\/abba3b27864aec87044c09f8ef314e7da895fc9c\/cras\/src\/server\/cras_bt_player.c\">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<h2>Improving security for all through research and threat intelligence sharing<\/h2>\n<p>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<p>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. <a href=\"https:\/\/docs.microsoft.com\/microsoft-365\/security\/defender-endpoint\/device-discovery?view=o365-worldwide\">Microsoft Defender for Endpoint&#8217;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<p>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<p><strong>Jonathan Bar Or<\/strong><\/p>\n<p>Microsoft 365 Defender Research Team<\/p>\n<p>The post <a rel=\"nofollow\" href=\"https:\/\/www.microsoft.com\/security\/blog\/2022\/08\/19\/uncovering-a-chromeos-remote-memory-corruption-vulnerability\/\">Uncovering a ChromeOS remote memory corruption vulnerability<\/a> appeared first on <a rel=\"nofollow\" href=\"https:\/\/www.microsoft.com\/security\/blog\">Microsoft Security Blog<\/a>.<\/p>\n<p><a href=\"https:\/\/www.microsoft.com\/security\/blog\/2022\/08\/19\/uncovering-a-chromeos-remote-memory-corruption-vulnerability\/\" target=\"bwo\" >https:\/\/blogs.technet.microsoft.com\/mmpc\/feed\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p><strong>Credit to Author: Katie McCafferty| Date: Fri, 19 Aug 2022 21:38:06 +0000<\/strong><\/p>\n<p>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<p>The post <a rel=\"nofollow\" href=\"https:\/\/www.microsoft.com\/security\/blog\/2022\/08\/19\/uncovering-a-chromeos-remote-memory-corruption-vulnerability\/\">Uncovering a ChromeOS remote memory corruption vulnerability<\/a> appeared first on <a rel=\"nofollow\" href=\"https:\/\/www.microsoft.com\/security\/blog\">Microsoft Security Blog<\/a>.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10759,10378],"tags":[27323,4500,10516,22453,714,10467],"class_list":["post-19899","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-security","tag-chromeos","tag-cybersecurity","tag-microsoft","tag-microsoft-security-intelligence","tag-security","tag-vulnerability"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/19899","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=19899"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/19899\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=19899"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=19899"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=19899"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}