{"redhatcve": [{"lastseen": "2022-06-08T11:03:29", "description": "A flaw was found in PackageKit in the way some of the methods exposed by the Transaction interface examines files. This issue allows a local user to measure the time the methods take to execute and know whether a file owned by root or other users exists.\n", "cvss3": {}, "published": "2022-03-15T16:43:07", "type": "redhatcve", "title": "CVE-2022-0987", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2022-0987"], "modified": "2022-06-08T09:29:31", "id": "RH:CVE-2022-0987", "href": "https://access.redhat.com/security/cve/cve-2022-0987", "cvss": {"score": 0.0, "vector": "NONE"}}], "mmpc": [{"lastseen": "2022-05-03T17:04:43", "description": "Microsoft has discovered several vulnerabilities, collectively referred to as Nimbuspwn, that could allow an attacker to elevate privileges to root on many Linux desktop endpoints. The vulnerabilities can be chained together to gain root privileges on Linux systems, allowing attackers to deploy payloads, like a root backdoor, and perform other malicious actions via arbitrary root code execution. Moreover, the Nimbuspwn vulnerabilities could potentially be leveraged as a vector for root access by more sophisticated threats, such as malware or ransomware, to achieve greater impact on vulnerable devices.\n\nWe discovered the vulnerabilities by listening to messages on the System Bus while performing code reviews and dynamic analysis on services that run as root, noticing an odd pattern in a systemd unit called _networkd-dispatcher_. Reviewing the code flow for _networkd-dispatcher_ revealed multiple security concerns, including directory traversal, symlink race, and time-of-check-time-of-use race condition issues, which could be leveraged to elevate privileges and deploy malware or carry out other malicious activities. We shared these vulnerabilities with the relevant maintainers through [Coordinated Vulnerability Disclosure](<https://www.microsoft.com/msrc/cvd?rtc=1>) (CVD) via [Microsoft Security Vulnerability Research](<https://www.microsoft.com/msrc/msvr>) (MSVR). Fixes for these vulnerabilities, now identified as [CVE-2022-29799](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29799>) and [CVE-2022-29800](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29800>), have been successfully deployed by the maintainer of the _networkd-dispatcher_, Clayton Craft. We wish to thank Clayton for his professionalism and collaboration in resolving those issues. Users of _networkd-dispatcher_ are encouraged to update their instances.\n\nAs organizational environments continue to rely on a diverse range of devices and systems, they require comprehensive solutions that provide cross-platform protection and a holistic view of their security posture to mitigate threats, such as Nimbuspwn. The growing number of vulnerabilities on Linux environments emphasize the need for strong monitoring of the platform\u2019s operating system and its components. Microsoft Defender for Endpoint enables organizations to gain this necessary visibility and detect such threats on [Linux devices](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint-linux?view=o365-worldwide>), allowing organizations to detect, manage, respond, and remediate vulnerabilities and threats across different platforms, including Windows, Linux, Mac, iOS, and Android.\n\nIn this blog post, we will share some information about the affected components and examine the vulnerabilities we uncovered. Detailing how our cross-domain visibility helps us uncover new and unknown threats to continually improve security, we are also sharing details from our research with the larger security community to underscore the importance of securing platforms and devices.\n\n## Background \u2013 D-Bus\n\n[D-Bus](<https://en.wikipedia.org/wiki/D-Bus>) (short for \u201cDesktop-Bus\u201d) is an inter-process communication channel (IPC) mechanism developed by the [freedesktop.org](<https://www.freedesktop.org/>) project. D-Bus is a software-bus and allows processes on the same endpoint to communicate by transmitting messages and responding to them. D-Bus supports two main ways of communicating:\n\n 1. Methods \u2013 used for request-response communications.\n 2. Signals \u2013 used for publish/subscribe communications.\n\nAn example of D-Bus usage would be receiving a video chat by a popular video conferencing app\u2013once a video is established, the video conferencing app could send a D-bus signal publishing that a call has started. Apps listening to that message could respond appropriately\u2013for example, mute their audio.\n\nThere are many D-Bus components shipped by default on popular Linux desktop environments. Since those components run at different privileges and respond to messages, D-Bus components are an attractive target for attackers. Indeed, there have been interesting vulnerabilities in the past related to buggy D-Bus services, including [USBCreator Elevation of Privilege](<https://unit42.paloaltonetworks.com/usbcreator-d-bus-privilege-escalation-in-ubuntu-desktop/>), [Blueman Elevation of Privilege by command injection](<https://bugzilla.redhat.com/show_bug.cgi?id=1892437>), and other similar scenarios.\n\nD-Bus exposes a global _System Bus_ and a per-session _Session Bus_. From an attacker\u2019s perspective, the System Bus is more attractive since it will commonly have services that run as root listening to it.\n\n### D-Bus name ownership\n\nWhen connecting to the D-Bus, components are assigned with a unique identifier, which mitigates against attacks abusing PID-recycling. The unique identifier starts with a colon and has numbers in it separated by dots, such as \u201c:1.337\u201d. Components can use the D-Bus API to own identifiable names such as \u201corg.freedesktop.Avahi\u201d or \u201ccom.ubuntu.SystemService\u201d. For D-Bus to allow such ownership, the requesting process context must be allowed under the D-Bus configuration files. Those configuration files are [well documented](<https://dbus.freedesktop.org/doc/dbus-daemon.1.html>) and maintained under _/usr/local/share/dbus-1/system.conf_ and _/usr/local/share/dbus-1/session.conf_ (on some systems under _/usr/local/dbus-1_ directly). Specifically, the default _system.conf_ does not allow ownership unless specified otherwise in other included configuration files (commonly under _/etc/dbus-1/system.d_).\n\nFigure 1: Different ownership policies for the System Bus and the Session Bus\n\nAdditionally, if the name requested already exists\u2013the request will not be granted until the owning process releases the name.\n\n## Vulnerability hunting\n\nOur team has started enumerating services that run as root and listen to messages on the System Bus, performing both code reviews and dynamic analysis. We have reported two information leak issues as a result:\n\n 1. [Directory Info Disclosure in Blueman](<https://github.com/blueman-project/blueman/security/advisories/GHSA-3r9p-m5c8-8mw8>)\n 2. [Directory Info Disclosure in PackageKit (CVE-2022-0987)](<https://access.redhat.com/security/cve/cve-2022-0987>)\n\nWhile these are interesting, their severity is low \u2013 an attacker can list files under directories that require high permissions to list files under. Then we started noticing interesting patterns in a [systemd unit](<https://en.wikipedia.org/wiki/Systemd>) called _networkd-dispatcher_. The goal of _networkd-dispatcher_ is to dispatch network status changes and optionally perform different scripts based on the new status. Interestingly, it runs on boot as root:\n\nFigure 2: _networkd-dispatcher_ running as root\n\n### Code flow for _networkd-dispatcher_\n\nUpon examination of the _networkd-dispatcher_ [source code](<https://gitlab.com/craftyguy/networkd-dispatcher>), we noticed an interesting flow:\n\n 1. The _register_ function registers a new signal receiver for the service \u201c_org.freedesktop.network1_\u201d on the System Bus, for the signal name \u201d_PropertiesChanged_\u201d.\n 2. The \u201d__receive_signal_\u201c signal handler will perform some basic checks on the object type being sent, concludes the changed network interface based on the object path being sent, and then concludes its new states\u2013\u201c_OperationalState_\u201d and \u201c_AdministrativeState_\u201d\u2013each fetched from the data. For any of those states\u2013if they aren\u2019t empty\u2013the \u201c_handle_state_\u201d method will get invoked.\n 3. The \u201c_handle_state_\u201d method simply invokes \u201c__handle_one_state_\u201c for each of those two states.\n 4. \u201c__handle_one_state_\u201d validates the state isn\u2019t empty and checks if it\u2019s different than the previous state. If it is, it will update the new state and invoke the \u201c__run_hooks_for_state_\u201d method, which is responsible of discovering and running the scripts for the new state.\n 5. \u201c__run_hooks_for_state_\u201d implements the following logic:\n * Discovers the script list by invoking the \u201c_get_script_list_\u201d method (which gets the new state as a string). This method simply calls \u201c_scripts_in_path_\u201d which is intended to return all the files under \u201c_/etc/networkd-dispatcher/<state>.d_\u201d that are owned by the root user and the root group, and are executable.\n * Sorts the script list.\n * Runs each script with [subprocess.Popen](<https://docs.python.org/3/library/subprocess.html#subprocess.Popen>) while supplying custom environment variables.\nFigure 3: _run_hooks_for_state source code - some parts omitted for brevity\n\nStep 5 has multiple security issues:\n\n 1. [_Directory traversal _](<https://en.wikipedia.org/wiki/Directory_traversal_attack>)_([CVE-2022-29799](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29799>))_: none of the functions in the flow sanitize the _OperationalState_ or the _AdministrativeState_. Since the states are used to build the script path, it is possible that a state would contain directory traversal patterns (e.g. \u201c_../../_\u201d) to escape from the \u201c_/etc/networkd-dispatcher_\u201d base directory.\n 2. [_Symlink race_](<https://en.wikipedia.org/wiki/Symlink_race>): both the script discovery and _subprocess.Popen_ follow symbolic links.\n 3. _Time-of-check-time-of-use (_[_TOCTOU_](<https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use>)_) race condition ([CVE-2022-29800](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29800>))_: there is a certain time between the scripts being discovered and them being run. An attacker can abuse this vulnerability to replace scripts that _networkd-dispatcher_ believes to be owned by root to ones that are not.\nFigure 4: Building the script list in the "scripts_in_path" method, including the vulnerable code with \u201csubdir\u201d poisoned.\n\n## Exploitation\n\nLet us assume an adversary has a malicious D-Bus component that can send an arbitrary signal. An attacker can therefore do the following:\n\n 1. Prepare a directory \u201d_/tmp/nimbuspwn_\u201d and plant a symlink \u201d_/tmp/nimbuspwn/poc.d_\u201c to point to \u201c_/sbin_\u201d. The _\u201c/sbin\u201d _directory was chosen specifically because it has many executables owned by root that do not block if run without additional arguments. This will abuse the _symlink race_ issue we mentioned earlier.\n 2. For every executable filename under \u201c_/sbin_\u201d owned by root, plant the same filename under \u201c_/tmp/nimbuspwn_\u201d. For example, if \u201c_/sbin/vgs_\u201d is executable and owned by root, plant an executable file \u201c_/tmp/nimbuspwn/vgs_\u201d with the desired payload. This will help the attacker win the race condition imposed by the _TOCTOU_ vulnerability.\n 3. Send a signal with the _OperationalState_ _\u201c../../../tmp/nimbuspwn/poc\u201d_. This abuses the _directory traversal_ vulnerability and escapes the script directory.\n 4. The _networkd-dispatcher_ signal handler kicks in and builds the script list from the directory _\u201c/etc/networkd-dispatcher/../../../tmp/nimbuspwn/poc.d\u201d_, which is really the symlink (_\u201c/tmp/nimbuspwn/poc.d\u201d_), which points to _\u201c/sbin\u201d_. Therefore, it creates a list composed of many executables owned by root.\n 5. Quickly change the symlink \u201c_/tmp/nimbuspwn/poc.d\u201d_ to point to \u201c_/tmp/nimbuspwn_\u201d. This abuses the _TOCTOU race condition_ vulnerability\u2013the script path changes without _networkd-dispatcher_ being aware.\n 6. The dispatcher starts running files that were initially under \u201c_/sbin_\u201d but in truth under the \u201c_/tmp/nimbuspwn_\u201d directory. Since the dispatcher \u201cbelieves\u201d those files are owned by root, it executes them blindly with subprocess.Popen as root. Therefore, our attacker has successfully exploited the vulnerability.\n\nNote that to win the _TOCTOU__ race condition_ with high probability, we plant many files that can potentially run. Our experiments show three attempts were enough to win the _TOCTOU__ race condition_.\n\nFigure 5: Flow-chart of the attack in three stages\n\nSince we do not wish to run the exploit every time we want to run as root, the payload that we ended up implementing leaves a root backdoor as such:\n\n 1. Copies _/bin/sh_ to _/tmp/sh_.\n 2. Turns the new _/tmp/sh_ it into a [Set-UID (SUID) binary](<https://attack.mitre.org/techniques/T1548/001/>).\n 3. Run _/tmp/sh -p_. The \u201c_-p_\u201d flag is necessary since modern shells drop privileges by design.\n\n### Owning the bus name\n\nThe astute reader will notice that the entire exploit elevates privileges assuming our exploit code can own the \u201c_org.freedesktop.network1_\u201d bus name. While this sounds non-trivial, we have found several environments where this happens. Specifically:\n\n 1. On many environments (e.g. Linux Mint) the service _systemd-networkd_ that normally owns the \u201c_org.freedesktop.network1_\u201d bus name does not start at boot by default.\n 2. Using [advanced hunting in Microsoft Defender for Endpoint](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/advanced-hunting-overview?view=o365-worldwide>) we were able to spot several processes running as the _systemd-network_ user (which is permitted to own the bus name we require) running arbitrary code from world-writable locations. These include several scenarios on specific environments that allow running arbitrary code as _systemd-network_, such as running a script from a world-writable directory. We attribute some of those scenarios to customer misconfigurations.\n\nThe query we used can also be run by Microsoft Defender for Endpoint customers:\n \n \n DeviceProcessEvents\n | where Timestamp > ago(5d)\n and AccountName == \"systemd-network\"\n and isnotempty(InitiatingProcessAccountName)\n and isnotempty(FileName)\n | project DeviceId, FileName, FolderPath, ProcessCommandLine\n \n\nWe were therefore able to exploit these scenarios and implement our own exploit:\n\nFigure 6: Our exploit implemented and winning the TOCTOU race\n\nWhile capable of running any arbitrary script as root, our exploit copies _/bin/sh_ to the _/tmp_ directory, sets _/tmp/sh_ as a [Set-UID (SUID) executable](<https://attack.mitre.org/techniques/T1548/001/>), and then invokes \u201c_/tmp/sh -p_\u201d. Note that the \u201c_-p_\u201d flag is necessary to force the shell to not drop privileges.\n\n## Hardening device security and detection strategy\n\nDespite the evolving threat landscape regularly delivering new threats, techniques, and attack capabilities, adversaries continue to focus on identifying and taking advantage of unpatched vulnerabilities and misconfigurations as a vector to access systems, networks, and sensitive information for malicious purposes. This constant bombardment of attacks spanning a wide range of platforms, devices, and other domains emphasizes the need for a comprehensive and proactive vulnerability management approach that can further identify and mitigate even previously unknown exploits and issues.\n\nMicrosoft\u2019s [threat and vulnerability management](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/next-gen-threat-and-vuln-mgt?view=o365-worldwide>) capabilities help organizations monitor their overall security posture, providing real-time insights into risk with continuous vulnerability discovery, contextualized intelligent prioritization, and seamless one-click flaw remediation. Leveraging our research into the Nimbuspwn vulnerabilities to improve solutions, our threat and vulnerability management already covers CVE-2022-29799 and CVE-2022-29800 and indicates such vulnerable devices in the threat and vulnerability module in [Microsoft Defender for Endpoint](<https://www.microsoft.com/security/business/threat-protection/endpoint-defender?rtc=1>).\n\nTo address the specific vulnerabilities at play, Microsoft Defender for Endpoint\u2019s [endpoint detection and response (EDR)](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/overview-endpoint-detection-response?view=o365-worldwide>) capabilities detect the directory traversal attack required to leverage Nimbuspwn. Additionally, the Microsoft Defender for Endpoint detection team has a generic detection for suspicious Set-UID process invocations, which detected our exploit without prior knowledge.\n\nFigure 7: Microsoft Defender for Endpoint detecting a suspicious SUID process used in our exploit\n\nDefending against the evolving threat landscape requires the ability to protect and secure users\u2019 computing experiences, be it a Windows or non-Windows device. Microsoft continuously enriches our protection technologies through robust research that protects users and organizations across all the major platforms every single day. This case displayed how the ability to coordinate such research via expert, cross-industry collaboration is vital to effectively mitigate issues, regardless of the vulnerable device or platform in use. By sharing our research and other forms of threat intelligence, we can continue to collaborate with the larger security community and strive to build better protection for all.\n\nJonathan Bar Or\n\nMicrosoft 365 Defender Research Team\n\nThe post [Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn](<https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/>) appeared first on [Microsoft Security Blog](<https://www.microsoft.com/security/blog>).", "cvss3": {}, "published": "2022-04-26T16:00:00", "type": "mmpc", "title": "Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2022-0987", "CVE-2022-29799", "CVE-2022-29800"], "modified": "2022-04-26T16:00:00", "id": "MMPC:964714DBE0836BC58772B765F91EA924", "href": "https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/", "cvss": {"score": 0.0, "vector": "NONE"}}], "mssecure": [{"lastseen": "2022-05-03T17:04:46", "description": "Microsoft has discovered several vulnerabilities, collectively referred to as Nimbuspwn, that could allow an attacker to elevate privileges to root on many Linux desktop endpoints. The vulnerabilities can be chained together to gain root privileges on Linux systems, allowing attackers to deploy payloads, like a root backdoor, and perform other malicious actions via arbitrary root code execution. Moreover, the Nimbuspwn vulnerabilities could potentially be leveraged as a vector for root access by more sophisticated threats, such as malware or ransomware, to achieve greater impact on vulnerable devices.\n\nWe discovered the vulnerabilities by listening to messages on the System Bus while performing code reviews and dynamic analysis on services that run as root, noticing an odd pattern in a systemd unit called _networkd-dispatcher_. Reviewing the code flow for _networkd-dispatcher_ revealed multiple security concerns, including directory traversal, symlink race, and time-of-check-time-of-use race condition issues, which could be leveraged to elevate privileges and deploy malware or carry out other malicious activities. We shared these vulnerabilities with the relevant maintainers through [Coordinated Vulnerability Disclosure](<https://www.microsoft.com/msrc/cvd?rtc=1>) (CVD) via [Microsoft Security Vulnerability Research](<https://www.microsoft.com/msrc/msvr>) (MSVR). Fixes for these vulnerabilities, now identified as [CVE-2022-29799](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29799>) and [CVE-2022-29800](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29800>), have been successfully deployed by the maintainer of the _networkd-dispatcher_, Clayton Craft. We wish to thank Clayton for his professionalism and collaboration in resolving those issues. Users of _networkd-dispatcher_ are encouraged to update their instances.\n\nAs organizational environments continue to rely on a diverse range of devices and systems, they require comprehensive solutions that provide cross-platform protection and a holistic view of their security posture to mitigate threats, such as Nimbuspwn. The growing number of vulnerabilities on Linux environments emphasize the need for strong monitoring of the platform\u2019s operating system and its components. Microsoft Defender for Endpoint enables organizations to gain this necessary visibility and detect such threats on [Linux devices](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint-linux?view=o365-worldwide>), allowing organizations to detect, manage, respond, and remediate vulnerabilities and threats across different platforms, including Windows, Linux, Mac, iOS, and Android.\n\nIn this blog post, we will share some information about the affected components and examine the vulnerabilities we uncovered. Detailing how our cross-domain visibility helps us uncover new and unknown threats to continually improve security, we are also sharing details from our research with the larger security community to underscore the importance of securing platforms and devices.\n\n## Background \u2013 D-Bus\n\n[D-Bus](<https://en.wikipedia.org/wiki/D-Bus>) (short for \u201cDesktop-Bus\u201d) is an inter-process communication channel (IPC) mechanism developed by the [freedesktop.org](<https://www.freedesktop.org/>) project. D-Bus is a software-bus and allows processes on the same endpoint to communicate by transmitting messages and responding to them. D-Bus supports two main ways of communicating:\n\n 1. Methods \u2013 used for request-response communications.\n 2. Signals \u2013 used for publish/subscribe communications.\n\nAn example of D-Bus usage would be receiving a video chat by a popular video conferencing app\u2013once a video is established, the video conferencing app could send a D-bus signal publishing that a call has started. Apps listening to that message could respond appropriately\u2013for example, mute their audio.\n\nThere are many D-Bus components shipped by default on popular Linux desktop environments. Since those components run at different privileges and respond to messages, D-Bus components are an attractive target for attackers. Indeed, there have been interesting vulnerabilities in the past related to buggy D-Bus services, including [USBCreator Elevation of Privilege](<https://unit42.paloaltonetworks.com/usbcreator-d-bus-privilege-escalation-in-ubuntu-desktop/>), [Blueman Elevation of Privilege by command injection](<https://bugzilla.redhat.com/show_bug.cgi?id=1892437>), and other similar scenarios.\n\nD-Bus exposes a global _System Bus_ and a per-session _Session Bus_. From an attacker\u2019s perspective, the System Bus is more attractive since it will commonly have services that run as root listening to it.\n\n### D-Bus name ownership\n\nWhen connecting to the D-Bus, components are assigned with a unique identifier, which mitigates against attacks abusing PID-recycling. The unique identifier starts with a colon and has numbers in it separated by dots, such as \u201c:1.337\u201d. Components can use the D-Bus API to own identifiable names such as \u201corg.freedesktop.Avahi\u201d or \u201ccom.ubuntu.SystemService\u201d. For D-Bus to allow such ownership, the requesting process context must be allowed under the D-Bus configuration files. Those configuration files are [well documented](<https://dbus.freedesktop.org/doc/dbus-daemon.1.html>) and maintained under _/usr/local/share/dbus-1/system.conf_ and _/usr/local/share/dbus-1/session.conf_ (on some systems under _/usr/local/dbus-1_ directly). Specifically, the default _system.conf_ does not allow ownership unless specified otherwise in other included configuration files (commonly under _/etc/dbus-1/system.d_).\n\nFigure 1: Different ownership policies for the System Bus and the Session Bus\n\nAdditionally, if the name requested already exists\u2013the request will not be granted until the owning process releases the name.\n\n## Vulnerability hunting\n\nOur team has started enumerating services that run as root and listen to messages on the System Bus, performing both code reviews and dynamic analysis. We have reported two information leak issues as a result:\n\n 1. [Directory Info Disclosure in Blueman](<https://github.com/blueman-project/blueman/security/advisories/GHSA-3r9p-m5c8-8mw8>)\n 2. [Directory Info Disclosure in PackageKit (CVE-2022-0987)](<https://access.redhat.com/security/cve/cve-2022-0987>)\n\nWhile these are interesting, their severity is low \u2013 an attacker can list files under directories that require high permissions to list files under. Then we started noticing interesting patterns in a [systemd unit](<https://en.wikipedia.org/wiki/Systemd>) called _networkd-dispatcher_. The goal of _networkd-dispatcher_ is to dispatch network status changes and optionally perform different scripts based on the new status. Interestingly, it runs on boot as root:\n\nFigure 2: _networkd-dispatcher_ running as root\n\n### Code flow for _networkd-dispatcher_\n\nUpon examination of the _networkd-dispatcher_ [source code](<https://gitlab.com/craftyguy/networkd-dispatcher>), we noticed an interesting flow:\n\n 1. The _register_ function registers a new signal receiver for the service \u201c_org.freedesktop.network1_\u201d on the System Bus, for the signal name \u201d_PropertiesChanged_\u201d.\n 2. The \u201d__receive_signal_\u201c signal handler will perform some basic checks on the object type being sent, concludes the changed network interface based on the object path being sent, and then concludes its new states\u2013\u201c_OperationalState_\u201d and \u201c_AdministrativeState_\u201d\u2013each fetched from the data. For any of those states\u2013if they aren\u2019t empty\u2013the \u201c_handle_state_\u201d method will get invoked.\n 3. The \u201c_handle_state_\u201d method simply invokes \u201c__handle_one_state_\u201c for each of those two states.\n 4. \u201c__handle_one_state_\u201d validates the state isn\u2019t empty and checks if it\u2019s different than the previous state. If it is, it will update the new state and invoke the \u201c__run_hooks_for_state_\u201d method, which is responsible of discovering and running the scripts for the new state.\n 5. \u201c__run_hooks_for_state_\u201d implements the following logic:\n * Discovers the script list by invoking the \u201c_get_script_list_\u201d method (which gets the new state as a string). This method simply calls \u201c_scripts_in_path_\u201d which is intended to return all the files under \u201c_/etc/networkd-dispatcher/<state>.d_\u201d that are owned by the root user and the root group, and are executable.\n * Sorts the script list.\n * Runs each script with [subprocess.Popen](<https://docs.python.org/3/library/subprocess.html#subprocess.Popen>) while supplying custom environment variables.\nFigure 3: _run_hooks_for_state source code - some parts omitted for brevity\n\nStep 5 has multiple security issues:\n\n 1. [_Directory traversal _](<https://en.wikipedia.org/wiki/Directory_traversal_attack>)_([CVE-2022-29799](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29799>))_: none of the functions in the flow sanitize the _OperationalState_ or the _AdministrativeState_. Since the states are used to build the script path, it is possible that a state would contain directory traversal patterns (e.g. \u201c_../../_\u201d) to escape from the \u201c_/etc/networkd-dispatcher_\u201d base directory.\n 2. [_Symlink race_](<https://en.wikipedia.org/wiki/Symlink_race>): both the script discovery and _subprocess.Popen_ follow symbolic links.\n 3. _Time-of-check-time-of-use (_[_TOCTOU_](<https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use>)_) race condition ([CVE-2022-29800](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29800>))_: there is a certain time between the scripts being discovered and them being run. An attacker can abuse this vulnerability to replace scripts that _networkd-dispatcher_ believes to be owned by root to ones that are not.\nFigure 4: Building the script list in the "scripts_in_path" method, including the vulnerable code with \u201csubdir\u201d poisoned.\n\n## Exploitation\n\nLet us assume an adversary has a malicious D-Bus component that can send an arbitrary signal. An attacker can therefore do the following:\n\n 1. Prepare a directory \u201d_/tmp/nimbuspwn_\u201d and plant a symlink \u201d_/tmp/nimbuspwn/poc.d_\u201c to point to \u201c_/sbin_\u201d. The _\u201c/sbin\u201d _directory was chosen specifically because it has many executables owned by root that do not block if run without additional arguments. This will abuse the _symlink race_ issue we mentioned earlier.\n 2. For every executable filename under \u201c_/sbin_\u201d owned by root, plant the same filename under \u201c_/tmp/nimbuspwn_\u201d. For example, if \u201c_/sbin/vgs_\u201d is executable and owned by root, plant an executable file \u201c_/tmp/nimbuspwn/vgs_\u201d with the desired payload. This will help the attacker win the race condition imposed by the _TOCTOU_ vulnerability.\n 3. Send a signal with the _OperationalState_ _\u201c../../../tmp/nimbuspwn/poc\u201d_. This abuses the _directory traversal_ vulnerability and escapes the script directory.\n 4. The _networkd-dispatcher_ signal handler kicks in and builds the script list from the directory _\u201c/etc/networkd-dispatcher/../../../tmp/nimbuspwn/poc.d\u201d_, which is really the symlink (_\u201c/tmp/nimbuspwn/poc.d\u201d_), which points to _\u201c/sbin\u201d_. Therefore, it creates a list composed of many executables owned by root.\n 5. Quickly change the symlink \u201c_/tmp/nimbuspwn/poc.d\u201d_ to point to \u201c_/tmp/nimbuspwn_\u201d. This abuses the _TOCTOU race condition_ vulnerability\u2013the script path changes without _networkd-dispatcher_ being aware.\n 6. The dispatcher starts running files that were initially under \u201c_/sbin_\u201d but in truth under the \u201c_/tmp/nimbuspwn_\u201d directory. Since the dispatcher \u201cbelieves\u201d those files are owned by root, it executes them blindly with subprocess.Popen as root. Therefore, our attacker has successfully exploited the vulnerability.\n\nNote that to win the _TOCTOU__ race condition_ with high probability, we plant many files that can potentially run. Our experiments show three attempts were enough to win the _TOCTOU__ race condition_.\n\nFigure 5: Flow-chart of the attack in three stages\n\nSince we do not wish to run the exploit every time we want to run as root, the payload that we ended up implementing leaves a root backdoor as such:\n\n 1. Copies _/bin/sh_ to _/tmp/sh_.\n 2. Turns the new _/tmp/sh_ it into a [Set-UID (SUID) binary](<https://attack.mitre.org/techniques/T1548/001/>).\n 3. Run _/tmp/sh -p_. The \u201c_-p_\u201d flag is necessary since modern shells drop privileges by design.\n\n### Owning the bus name\n\nThe astute reader will notice that the entire exploit elevates privileges assuming our exploit code can own the \u201c_org.freedesktop.network1_\u201d bus name. While this sounds non-trivial, we have found several environments where this happens. Specifically:\n\n 1. On many environments (e.g. Linux Mint) the service _systemd-networkd_ that normally owns the \u201c_org.freedesktop.network1_\u201d bus name does not start at boot by default.\n 2. Using [advanced hunting in Microsoft Defender for Endpoint](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/advanced-hunting-overview?view=o365-worldwide>) we were able to spot several processes running as the _systemd-network_ user (which is permitted to own the bus name we require) running arbitrary code from world-writable locations. These include several scenarios on specific environments that allow running arbitrary code as _systemd-network_, such as running a script from a world-writable directory. We attribute some of those scenarios to customer misconfigurations.\n\nThe query we used can also be run by Microsoft Defender for Endpoint customers:\n \n \n DeviceProcessEvents\n | where Timestamp > ago(5d)\n and AccountName == \"systemd-network\"\n and isnotempty(InitiatingProcessAccountName)\n and isnotempty(FileName)\n | project DeviceId, FileName, FolderPath, ProcessCommandLine\n \n\nWe were therefore able to exploit these scenarios and implement our own exploit:\n\nFigure 6: Our exploit implemented and winning the TOCTOU race\n\nWhile capable of running any arbitrary script as root, our exploit copies _/bin/sh_ to the _/tmp_ directory, sets _/tmp/sh_ as a [Set-UID (SUID) executable](<https://attack.mitre.org/techniques/T1548/001/>), and then invokes \u201c_/tmp/sh -p_\u201d. Note that the \u201c_-p_\u201d flag is necessary to force the shell to not drop privileges.\n\n## Hardening device security and detection strategy\n\nDespite the evolving threat landscape regularly delivering new threats, techniques, and attack capabilities, adversaries continue to focus on identifying and taking advantage of unpatched vulnerabilities and misconfigurations as a vector to access systems, networks, and sensitive information for malicious purposes. This constant bombardment of attacks spanning a wide range of platforms, devices, and other domains emphasizes the need for a comprehensive and proactive vulnerability management approach that can further identify and mitigate even previously unknown exploits and issues.\n\nMicrosoft\u2019s [threat and vulnerability management](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/next-gen-threat-and-vuln-mgt?view=o365-worldwide>) capabilities help organizations monitor their overall security posture, providing real-time insights into risk with continuous vulnerability discovery, contextualized intelligent prioritization, and seamless one-click flaw remediation. Leveraging our research into the Nimbuspwn vulnerabilities to improve solutions, our threat and vulnerability management already covers CVE-2022-29799 and CVE-2022-29800 and indicates such vulnerable devices in the threat and vulnerability module in [Microsoft Defender for Endpoint](<https://www.microsoft.com/security/business/threat-protection/endpoint-defender?rtc=1>).\n\nTo address the specific vulnerabilities at play, Microsoft Defender for Endpoint\u2019s [endpoint detection and response (EDR)](<https://docs.microsoft.com/microsoft-365/security/defender-endpoint/overview-endpoint-detection-response?view=o365-worldwide>) capabilities detect the directory traversal attack required to leverage Nimbuspwn. Additionally, the Microsoft Defender for Endpoint detection team has a generic detection for suspicious Set-UID process invocations, which detected our exploit without prior knowledge.\n\nFigure 7: Microsoft Defender for Endpoint detecting a suspicious SUID process used in our exploit\n\nDefending against the evolving threat landscape requires the ability to protect and secure users\u2019 computing experiences, be it a Windows or non-Windows device. Microsoft continuously enriches our protection technologies through robust research that protects users and organizations across all the major platforms every single day. This case displayed how the ability to coordinate such research via expert, cross-industry collaboration is vital to effectively mitigate issues, regardless of the vulnerable device or platform in use. By sharing our research and other forms of threat intelligence, we can continue to collaborate with the larger security community and strive to build better protection for all.\n\nJonathan Bar Or\n\nMicrosoft 365 Defender Research Team\n\nThe post [Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn](<https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/>) appeared first on [Microsoft Security Blog](<https://www.microsoft.com/security/blog>).", "cvss3": {}, "published": "2022-04-26T16:00:00", "type": "mssecure", "title": "Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2022-0987", "CVE-2022-29799", "CVE-2022-29800"], "modified": "2022-04-26T16:00:00", "id": "MSSECURE:964714DBE0836BC58772B765F91EA924", "href": "https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/", "cvss": {"score": 0.0, "vector": "NONE"}}]}
CVE-2022-0987
