A privilege escalation flaw in udev

A vulnerability in udev, the user-space tool that manages the Linux /dev tree, has left unpatched systems vulnerable to a local root privilege escalation. Exploits are already circulating on the full-disclosure mailing list, so it is rather important for users and administrators to update their systems. The problem was caused by the way udev processes the messages it receives—certain kinds of messages, which could be generated by user processes, were not considered. That oversight led to the vulnerability.

The ever-expanding nature of the /dev tree, along with the rise of more dynamic hardware environments, led to the creation of udev in 2003. It replaced the devfs filesystem that was an earlier attempt to solve those problems. Unfortunately, devfs codified device naming policy into the kernel—something the kernel hackers try to avoid. By moving those decisions to user space with udev, that problem—along with a number of others—was resolved.

In order for udevd (the udev daemon) to do its job, it needs a way to be informed by the kernel when devices come and go—typically because the user attached or detached some device. A standard Linux way to send messages between the kernel and user space is via a netlink socket. Netlink sockets are an inter-process communication (IPC) mechanism that is geared for kernel to user space (and vice versa) IPC. It provides the well-understood sockets API to user space programs and is a much more flexible IPC mechanism than other possible choices.

One of the nice features of netlink sockets is the ability to multicast messages (i.e. a message sent to multiple recipients). Each netlink protocol type can have up to 32 multicast groups associated with it. Typically, multicast messages can only be sent and received by root, though some netlink protocol types will allow non-root processes to send and/or receive multicast messages. In fact, a recent change to the kernel allows non-root processes to receive—but not send—the udev multicast messages (which are also known as uevents).

Since only root processes can send the multicast uevents, it would seem there is no hole to exploit. Unfortunately, no one considered unicast messages. Any process can send a unicast netlink message to any other process, just by addressing it to a particular pid. It is up to the recipient to decide whether to accept and process the message. Because these unicast messages fell through the cracks, udevd would happily process them—creating devices as specified by a potentially malicious user. One of the more obvious exploits would be to create world-writeable block device corresponding to the root filesystem—other, nastier exploits are likely possible as well.

The fix was straightforward: enabling credentials (a header placed on each message by the kernel that includes the uid and pid of the sender) for the netlink socket, then requiring that all messages received have a uid of zero, which Kay Sievers added on April 8. Scott James Remnant added some additional checks shortly thereafter, requiring that messages received are not unicast and have been sent by the kernel.

Sievers says that either patch "alone would be sufficient" to fix the problem and that doing both is, in some sense, defensive programming. The credentials check is needed for upcoming changes, he said, and Remnant's checks will take care of a theoretical concern: "a confined root process inside SELinux or AppArmor jail, which in fact is not root in the usual sense, has no privileges, but could have the uid 0". While Sievers didn't think the theory was particularly viable, checking for a sender pid of zero (as Remnant's change does) will take care of that problem as well.

This vulnerability illustrates a fairly common mistake: not considering all of the ways that input can reach a program. Every input mechanism factors into the "attack surface" of a program (or system). In this case, messages that—up until very recently at least—couldn't even be seen by non-root processes, could be sent by them. It is not uncommon for developers to focus on the "normal" usage of an input mechanism and miss a lesser, but still valid, use.

It is interesting to see that this vulnerability has a strange overlap with the capabilities flaw we reported on last week. In both cases, an exploit would use a device node created by mknod(), which is, itself, an uncommonly-used system call. These are the kinds of places that attackers are likely to focus their efforts. One hopes that other users of netlink sockets—routing daemons, netfilter, firewall applications, and others—have examined their code for similar problems.