Ubuntu
selinux package

/etc/init.d/selinux possible privilege escalation

Bug #876994 reported by Hayawardh Vijayakumar on 2011-10-18

258

This bug affects 1 person

	Status	Importance	Assigned to
selinux (Ubuntu)	Fix Released	Low	Jamie Strandboge
Hardy	Fix Released	Low	Jamie Strandboge
Lucid	Fix Released	Low	Jamie Strandboge
Maverick	Fix Released	Low	Jamie Strandboge
Natty	Fix Released	Low	Jamie Strandboge
Oneiric	Fix Released	Low	Jamie Strandboge
Precise	Fix Released	Low	Jamie Strandboge

Bug Description

Dear All,

I think there might be a problem with the startup script /etc/init.d/selinux that allows an unprivileged user to create a file in any directory. I am copying a message I sent to Jamie Strandboge -

In my Ubuntu 11.10 (Oneiric), the script /etc/init.d/selinux contains:

statusfile=/.autorelabel
...
lockfile=/var/lock/selinux-relabel
...
# Start only creates the lock
start() {
        log_daemon_msg "Starting SELinux autorelabel"
        if [ -e $statusfile ]; then
                log_warning_msg "A relabel has already been requested. Please reboot to finish relabeling your system."
                log_end_msg 0
        else
                /usr/bin/touch $lockfile
                log_end_msg 0
        fi
}

As /var/lock is world writable, a user could presumably create a file in any location by making this a symlink. Admittedly, /var/lock does not persist across reboots (tmpfs), and once selinux-relabel has been created by root it cannot be changed, but if the administrator for example restarts the daemon, in this gap, the user could create the file. I confirmed this to be the case on my machine. Or, if selinux is installed for the first time, then too shall a link be followed if it is pre-created.

Please let me know if further details are required.

Thanks,
Hayawardh Vijayakumar.

Details:
# lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10

# apt-cache policy selinux
Installed: 1:0.9
Candidate: 1:0.9
Version table:
*** 1:0.9 0
500 http://us.archive.ubuntu.com/ubuntu/ oneiric/universe Packages
100 /var/lib/dpkg/status

To exploit:
When SELinux is not installed or the autorelabel daemon is stopped through e.g., /etc/init.d/selinux stop
unpriv-user$ ln -s /etc/file_to_create /var/lock/selinux-relabel

When /etc/init.d/selinux start happens,
# ls -l /etc/file_to_create
-rw-r--r--. 1 root root 0 2011-10-17 20:29 /etc/file_to_create

EDIT: This was run under a kernel.org kernel that did not have yama installed. As Marc notes, under default yama configuration, this attack shall be blocked by the system due to yama (Maverick upwards).

See original description

Related branches

lp:ubuntu/precise/selinux

lp:ubuntu/maverick-security/selinux

lp:ubuntu/oneiric-security/selinux

lp:ubuntu/hardy-security/selinux

lp:ubuntu/natty-security/selinux

lp:ubuntu/lucid-security/selinux

CVE References

2011-3151

Hayawardh Vijayakumar (hayawardh) on 2011-10-18

description:

updated

Revision history for this message

Jamie Strandboge (jdstrand) wrote on 2011-10-21:

Thank you for using Ubuntu and creating a bug. In analyzing your report it is clear that this can be used to create files like /etc/nologin, /forcefsck and others. The initscript should instead be using 'touch --no-dereference' instead. Due to the nature of when the init script runs I am giving this a preliminary priority of 'Low'.

Changed in selinux (Ubuntu):
importance:	Undecided → Low
status:	New → Triaged

Revision history for this message

Jamie Strandboge (jdstrand) wrote on 2011-10-21:

As the /etc/init.d/selinux script is an Ubuntu-only script, we'll provide an update for it.

Revision history for this message

Marc Deslauriers (mdeslaur) wrote on 2011-10-22:

Please use CVE-2011-3151 for this issue.

Revision history for this message

Jamie Strandboge (jdstrand) wrote on 2011-10-22:

Here is the patch I plan to roll out. It simply adds '--no-dereference' to touch (I also did it for the statusfile for good form, even though it isn't strictly necessary).

Changed in selinux (Ubuntu Lucid):
status:	New → In Progress
importance:	Undecided → Low
assignee:	nobody → Jamie Strandboge (jdstrand)
Changed in selinux (Ubuntu Maverick):
status:	New → In Progress
importance:	Undecided → Low
assignee:	nobody → Jamie Strandboge (jdstrand)
Changed in selinux (Ubuntu Natty):
status:	New → In Progress
importance:	Undecided → Low
assignee:	nobody → Jamie Strandboge (jdstrand)
Changed in selinux (Ubuntu Oneiric):
status:	New → In Progress
importance:	Undecided → Low
assignee:	nobody → Jamie Strandboge (jdstrand)
Changed in selinux (Ubuntu Precise):
status:	Triaged → In Progress
assignee:	nobody → Jamie Strandboge (jdstrand)
Changed in selinux (Ubuntu Hardy):
status:	New → In Progress
importance:	Undecided → Low
assignee:	nobody → Jamie Strandboge (jdstrand)

Revision history for this message

Hayawardh Vijayakumar (hayawardh) wrote on 2011-10-22:

Dear Jamie,

Thanks for the patch, it looks good to me. However, is --no-dereference available for all Ubuntu versions you list? It seems to me that this option has been added recently, for in my Ubuntu Lucid (10.04.2 LTS), touch does not have that option, though Maverick upwards has it.

Thanks,
Hayawardh

Revision history for this message

Marc Deslauriers (mdeslaur) wrote on 2011-10-26:

FYI, Maverick and newer probably aren't affected by this because of YAMA...

Revision history for this message

Hayawardh Vijayakumar (hayawardh) wrote on 2011-10-26:

Ok, I can confirm that Marc is right.

I was using a kernel.org kernel when I ran the tests initially, so I did not run into yama.
I shall edit my initial post to note this.

If I use the default Ubuntu kernel for my Oneiric :

unpriv-user$ ln -s /etc/file_to_create /var/lock/selinux-relabel

root@machine:~# /etc/init.d/selinux start
* Starting SELinux autorelabel
/usr/bin/touch: cannot touch `/var/lock/selinux-relabel': Permission denied

root@machine:~# uname -r
2.6.38-8-generic-pae

root@machine:/proc/sys/kernel/yama# cat protected_sticky_symlinks
1

If however protected_sticky_symlinks is turned set to 0, then the link is followed, so it seems prudent to fix it anyway.

description:

updated

Revision history for this message

Jamie Strandboge (jdstrand) wrote on 2011-12-21:

I can confirm Marc's assessment regarding Yama. On Ubuntu 10.04 (without yama):
$ ln -s /forcefsck /var/lock/selinux-relabel
$ sudo touch /var/lock/selinux-relabel
$ test -e /forcefsck && echo yes
yes
$

On 10.10 and higher (all versions confirmed):
$ ln -s /forcefsck /var/lock/selinux-relabel
$ sudo touch /var/lock/selinux-relabel
touch: cannot touch `/var/lock/selinux-relabel': Permission denied
$ test -e /forcefsck && echo yes
$

Changed in selinux (Ubuntu Maverick):
status:	In Progress → Invalid
Changed in selinux (Ubuntu Natty):
status:	In Progress → Invalid
Changed in selinux (Ubuntu Oneiric):
status:	In Progress → Invalid
Changed in selinux (Ubuntu Precise):
status:	In Progress → Invalid

Revision history for this message

Launchpad Janitor (janitor) wrote on 2011-12-21:

This bug was fixed in the package selinux - 1:0.10

---------------
selinux (1:0.10) precise; urgency=low

  * Fix unsafe lockfile creation. The scope of this is limited by when this
    script is run. On Ubuntu 10.10 and higher, Yama blocks exploitation of
    this issue, but we want to fix this on Ubuntu 10.04 LTS (which doesn't
    have Yama) and so this package is provided for upgrades. (LP: #876994)
-- Jamie Strandboge <email address hidden> Wed, 21 Dec 2011 12:20:37 -0600

Changed in selinux (Ubuntu Precise):
status:	Invalid → Fix Released

Revision history for this message

Jamie Strandboge (jdstrand) wrote on 2011-12-21:

#10

selinux_0.10~10.04.1.debdiff Edit (2.1 KiB, text/plain)

Here is an updated patch for 10.04. It uses mkdir instead of touch which will solve the issue fine. Because 10.04 - 12.04 all have selinux 0.9, we actually do need to provide updated packages their for upgrades. I have upload 0.10 to 12.04 with this patch and updated packages for all stable releases to the security ppa.

Changed in selinux (Ubuntu Maverick):
status:	Invalid → Fix Committed
Changed in selinux (Ubuntu Natty):
status:	Invalid → Fix Committed
Changed in selinux (Ubuntu Oneiric):
status:	Invalid → Fix Committed
Changed in selinux (Ubuntu Lucid):
status:	In Progress → Fix Committed
Changed in selinux (Ubuntu Hardy):
status:	In Progress → Fix Committed
visibility:	private → public

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-01-04:

#11

This bug was fixed in the package selinux - 1:0.10~11.10.1

---------------
selinux (1:0.10~11.10.1) oneiric-security; urgency=low

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-01-04:

#12

This bug was fixed in the package selinux - 1:0.10~11.04.1

---------------
selinux (1:0.10~11.04.1) natty-security; urgency=low

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-01-04:

#13

This bug was fixed in the package selinux - 1:0.10~10.10.1

---------------
selinux (1:0.10~10.10.1) maverick-security; urgency=low

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-01-04:

#14

This bug was fixed in the package selinux - 1:0.10~10.04.1

---------------
selinux (1:0.10~10.04.1) lucid-security; urgency=low

  * SECURITY UPDATE: fix unsafe lockfile creation. The scope of this
    is limited by when this script is run, but it is still worthwhile
    to get this cleaned up (LP: #876994)
-- Jamie Strandboge <email address hidden> Wed, 21 Dec 2011 11:27:22 -0600

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-01-04:

#15

This bug was fixed in the package selinux - 0.2+0.10init1

---------------
selinux (0.2+0.10init1) hardy-security; urgency=low

Changed in selinux (Ubuntu Hardy):
status:	Fix Committed → Fix Released
Changed in selinux (Ubuntu Lucid):
status:	Fix Committed → Fix Released
Changed in selinux (Ubuntu Maverick):
status:	Fix Committed → Fix Released
Changed in selinux (Ubuntu Natty):
status:	Fix Committed → Fix Released
Changed in selinux (Ubuntu Oneiric):
status:	Fix Committed → Fix Released