{"id":112701,"date":"2022-04-26T09:00:00","date_gmt":"2022-04-26T16:00:00","guid":{"rendered":""},"modified":"2025-06-20T02:28:49","modified_gmt":"2025-06-20T09:28:49","slug":"microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2022\/04\/26\/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn\/","title":{"rendered":"Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

We 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<\/em>. Reviewing the code flow for networkd-dispatcher<\/em> 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<\/a> (CVD) via Microsoft Security Vulnerability Research<\/a> (MSVR). Fixes for these vulnerabilities, now identified as CVE-2022-29799<\/a> and CVE-2022-29800<\/a>, have been successfully deployed by the maintainer of the networkd-dispatcher<\/em>, Clayton Craft. We wish to thank Clayton for his professionalism and collaboration in resolving those issues. Users of networkd-dispatcher<\/em> are encouraged to update their instances.<\/p>\n\n\n\n

As 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<\/a>, allowing organizations to detect, manage, respond, and remediate vulnerabilities and threats across different platforms, including Windows, Linux, Mac, iOS, and Android.<\/p>\n\n\n\n

In 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.<\/p>\n\n\n\n

Background \u2013 D-Bus<\/h2>\n\n\n\n

D-Bus<\/a> (short for \u201cDesktop-Bus\u201d) is an inter-process communication channel (IPC) mechanism developed by the freedesktop.org<\/a> 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:<\/p>\n\n\n\n

    \n
  1. Methods \u2013 used for request-response communications.<\/li>\n\n\n\n
  2. Signals \u2013 used for publish\/subscribe communications.<\/li>\n<\/ol>\n\n\n\n

    An 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.<\/p>\n\n\n\n

    There 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<\/a>, Blueman Elevation of Privilege by command injection<\/a>, and other similar scenarios.<\/p>\n\n\n\n

    D-Bus exposes a global System Bus<\/em> and a per-session Session Bus<\/em>. From an attacker\u2019s perspective, the System Bus is more attractive since it will commonly have services that run as root listening to it.<\/p>\n\n\n\n

    D-Bus name ownership<\/h3>\n\n\n\n

    When 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<\/a> and maintained under \/usr\/local\/share\/dbus-1\/system.conf<\/em> and \/usr\/local\/share\/dbus-1\/session.conf<\/em> (on some systems under \/usr\/local\/dbus-1<\/em> directly). Specifically, the default system.conf<\/em> does not allow ownership unless specified otherwise in other included configuration files (commonly under \/etc\/dbus-1\/system.d<\/em>).<\/p>\n\n\n\n

    \"Figure
    Figure 1: Different ownership policies for the System Bus and the Session Bus<\/figcaption><\/figure>\n\n\n\n

    Additionally, if the name requested already exists\u2013the request will not be granted until the owning process releases the name.<\/p>\n\n\n\n

    Vulnerability hunting<\/h2>\n\n\n\n

    Our 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:<\/p>\n\n\n\n

      \n
    1. Directory Info Disclosure in Blueman<\/a><\/li>\n\n\n\n
    2. Directory Info Disclosure in PackageKit (CVE-2022-0987)<\/a><\/li>\n<\/ol>\n\n\n\n

      While 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<\/a> called networkd-dispatcher<\/em>. The goal of networkd-dispatcher<\/em> is to dispatch network status changes and optionally perform different scripts based on the new status. Interestingly, it runs on boot as root:<\/p>\n\n\n\n

      \"Figure
      Figure 2: networkd-dispatcher<\/em> running as root<\/figcaption><\/figure>\n\n\n\n

      Code flow for networkd-dispatcher<\/em><\/h3>\n\n\n\n

      Upon examination of the networkd-dispatcher<\/em> source code<\/a>, we noticed an interesting flow:<\/p>\n\n\n\n

        \n
      1. The register<\/em> function registers a new signal receiver for the service \u201corg.freedesktop.network1<\/em>\u201d on the System Bus, for the signal name \u201dPropertiesChanged<\/em>\u201d.<\/li>\n\n\n\n
      2. The \u201d_receive_signal<\/em>\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\u201cOperationalState<\/em>\u201d and \u201cAdministrativeState<\/em>\u201d\u2013each fetched from the data. For any of those states\u2013if they aren\u2019t empty\u2013the \u201chandle_state<\/em>\u201d method will get invoked.<\/li>\n\n\n\n
      3. The \u201chandle_state<\/em>\u201d method simply invokes \u201c_handle_one_state<\/em>\u201c for each of those two states.<\/li>\n\n\n\n
      4. \u201c_handle_one_state<\/em>\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<\/em>\u201d method, which is responsible of discovering and running the scripts for the new state.<\/li>\n\n\n\n
      5. \u201c_run_hooks_for_state<\/em>\u201d implements the following logic:\n