USBCreator D-Bus Privilege Escalation in Ubuntu Desktop

By

Category: Unit 42

Tags: , , ,

This post is also available in: 日本語 (Japanese)

 

Executive Summary

A vulnerability in the USBCreator D-Bus interface allows an attacker with access to a user in the sudoer group to bypass the password security policy imposed by the sudo program. The vulnerability allows an attacker to overwrite arbitrary files with arbitrary content, as root - without supplying a password. This trivially leads to elevated privileges, for instance, by overwriting the shadow file and setting a password for root. The issue was resolved in June when Ubuntu patched the relevant packages in response to a vulnerability disclosure from Unit 42.

A Short Introduction to D-Bus

Ubuntu desktop utilizes D-Bus as its inter-process communications (IPC) mediator. On Ubuntu, there are several message buses that run concurrently: A system bus, which is mainly used by privileged services to expose system-wide relevant services, and one session bus for each logged in user, which exposes services that are only relevant to that specific user. Since we will try to elevate our privileges, we will mainly focus on the system bus as the services there tend to run with higher privileges (i.e. root). Note that the D-Bus architecture utilizes one ‘router’ per session bus, which redirects client messages to the relevant services they are trying to interact with. Clients need to specify the address of the service to which they want to send messages.

Each service is defined by the objects and interfaces that it exposes. We can think of objects as instances of classes in standard OOP languages. Each unique instance is identified by its object path – a string which resembles a file system path that uniquely identifies each object that the service exposes. A standard interface that will help with our research is the org.freedesktop.DBus.Introspectable interface. It contains a single method, Introspect, which returns an XML representation of the methods, signals and properties supported by the object. This blog post focuses on methods and ignores properties and signals.

I used two tools to communicate with the D-Bus interface: CLI tool named gdbus, which allows to easily call D-Bus exposed methods in scripts, and D-Feet, a Python based GUI tool that helps to enumerate the available services on each bus and to see which objects each service contains.

Figure 1. D-Feet main window

Figure 2. D-Feet interface window

D-Feet is an excellent tool that proved essential during my research. On the left pane in Figure 1 you can see all the various services that have registered with the D-Bus daemon system bus (note the select System Bus button on the top). I selected the org.debin.apt service, and D-Feet automatically queried the service for all the available objects. Once I selected a specific object, the set of all interfaces, with their respective methods properties and signals are listed, as seen in Figure 2. Note that we also get the signature of each IPC exposed method.

We can also see the pid of the process that hosts each service, as well as its command line. This is a very useful feature, since we can validate that the target service we are inspecting indeed runs with higher privileges. Some services on the System bus don’t run as root, and thus are less interesting to research.

D-Feet also allows one to call the various methods. In the method input screen we can specify a list of Python expressions, delimited by commas, to be interpreted as the parameters to the invoked function, shown in Figure 3. Python types are marshaled to D-Bus types and passed to the service.

Figure 3. Calling D-Bus Methods through D-Feet

Some methods require authentication before allowing us to invoke them. We will ignore these methods, since our goal is to elevate our privileges without credentials in the first place.

Figure 4. A method that requires authorization

Also note that some of the services query another D-Bus service named org.freedeskto.PolicyKit1 whether a user should be allowed to perform certain actions or not. We will come back to this later in this blog post.

The Vulnerability

While researching the various D-Bus services, I looked for privileged services that act on behalf of an unprivileged user, requiring no authentication, and of course having user-controlled input that affects these operations. Without proper sanitation and validation on user input, a simple operation such as invoking a program or doing some file system I/O might lead to a compromised system.

The specific service that was vulnerable is com.ubuntu.USBCreator. Under the object denoted by /com/ubuntu/USBCreator resides the Image method. This method is used internally by Ubuntu’s USB Creator tool.

Figure 5. The com.ubuntu.USBCreator service

Figure 6. The Image method of /com/ubuntu/USBCreator

Inspecting this service, we can see it is privileged:

Figure 7. Shows service is privileged

As this service is implemented in Python, we can simply inspect the relevant source code. First we notice that the required privilege to interact with this method is com.ubuntu.usbcreator.image. We can see from the source code that polkit will be queried whether the requesting user is authorized for this request (in line 172).

Figure 8. USBCreator source code

Checking polkit’s configuration files, shown in Figure 9, we see that the Unix group sudo is entitled this capability. The relevant files reside under /var/lib/polkit-1/localauthority – specifically the file we are inspecting is /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla.

Figure 9. The section that starts at line 26 specified which groups are allowed to access the com.ubuntu.usbcreator.image capability

Inspecting the source code for the service, we see that it contains a Python implementation of the Unix tool dd. This tool can be used, among other things, to copy files between locations. The input to the method _builtin_dd is taken directly from user input. Furthermore, no path sanitation checks are performed on the source or target path, and no password prompts are being used – this allows a user to overwrite arbitrary files on the filesystem, as root, with no password prompting, as seen in Figure 10.

Figure 10. Creating files as root without supplying a password

Conclusion

We are not aware of any active exploitation of this vulnerability. Ubuntu now requires password authentication to launch USBCreator, following the release of a patch for the bug on June 18. Palo Alto Networks endpoint protection and response offering, Traps, can prevent exploitation of this vulnerability through its Behavioral Threat Protection mechanism.