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
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.
to post comments)