LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityA privilege escalation flaw in udevA 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.
Brief items The voting machine industry looks at open sourceHere is a report from the Election Technology Council [PDF] giving the voting machine industry's view of open source software. It's ... interesting. "The level of accountability present within an open source product offering is weakened due to its diffuse contributor base and lack of clear liability. Public oversight is arguably just as diminished in an open source environment since the layperson is unable to read and understand software source code adequately enough to ensure total access and comprehension. If a third party is charged with this oversight function to remedy this situation, this is would be no different than any other regulatory process that institutionalizes an oversight function." (Seen on Freedom To Tinker, where Dan Wallach adds several comments of his own).
The details on loading rootkits via /dev/memFor the curious, here is the paper describing rootkit injection via /dev/mem [PDF]. As expected, there's not a whole lot that's truly new, though there are some clever techniques for getting the kernel to allocate memory for the injected code. The authors note that, indeed, the STRICT_DEVMEM configuration option will block this attack. "Until recently there was no protection inside the kernel main- line, although SELinux has limited seeks above the first megabyte of memory for a few years. Users of RHEL and other distributions have been safe for some time now."
New vulnerabilities apt: return code not checked
clamav: multiple vulnerabilities
cups: integer overflow
cups: multiple vulnerabilities
firefox: multiple vulnerabilities
git-core: privilege escalation
kernel: privilege escalation
mpg123: user-assisted execution of arbitrary code
phpMyAdmin: insufficient output sanitizing
poppler: multiple vulnerabilities
slurm-llnl: privilege escalation
udev: multiple vulnerabilities
xine-lib: integer overflow
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||