The /proc vulnerability

A second local privilege escalation bug has been found recently in the 2.6 kernel series. The first, covered by LWN last week, configured processes to dump core in directories not normally writable by the user. The most recent vulnerability exploits the setuid permissions bit on files in the /proc filesystem and a kernel race. In both cases, the result is root privileges for interested local users.

The first indication of the vulnerability came as a working exploit posted to the full-disclosure mailing list. The exploit uses an mmap() of a large file on the disk to slow the system down enough to exploit a race condition in the /proc filesystem handling. Permissions for the /proc/self/environ file can be set with the setuid bit 'on' and prctl() can be used to set the owner of that file to root. Tacking an a.out executable onto the environ file allows a local user to get a root shell.

The fix is fairly obvious: setuid and setgid bits do not make any sense for /proc filesystem entries and removing that 'feature' fixes the problem. The stable 2.6 kernels were patched the same day as the exploit was released and a tweak to the original fix was released the next day.

A fairly simple workaround is to mount (or remount) /proc with the nosuid flag. That flag will prevent the setuid/setgid bits from having any affect for files on that filesystem. It should be noted that this workaround was the right thing to do for /proc all along; nothing good can come from allowing those bits to be used. Distributions should take a look at tightening these kinds of restrictions and help their users avoid these kinds of problems whenever possible.

Systems that have sufficiently restricted SELinux configurations were not affected by this vulnerability. For example, the targeted policy in enforcing mode that is the default for Red Hat Enterprise Linux 4 will not allow setting those bits on /proc files. In addition, kernels that did not have a.out support enabled would not be affected by this exploit, but there may be other ways to exploit the bug without using an a.out binary. Even so, this vulnerability is a good example of why it makes sense to disable unused functionality, even if it doesn't have any immediate security implementations. Most currently-running Linux systems have probably never seen an a.out binary; they certainly do not need that format enabled in their kernels.

It is fairly common for local privilege escalation issues to be given insufficient attention by system administrators because their systems either have no login user accounts or trust the people who do have them. Unfortunately, there is often a significant risk even to those kinds of systems. All that it takes is an exploit in a web program or other network service that allows a malicious user to get a shell. That shell will be running with the permissions of the user that runs the exploited service ('apache' for example), but a privilege escalation can allow that limited shell access to become a full takeover of the box. Any network accessible system should be considered vulnerable to this kind of problem and be patched accordingly.