Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
If you didn't already encounter it, there is a local root exploit out in the wild for 64-bit Linux machines.

We're running that on the cluster (and on other servers), but we really need to lock down any machines with public access... the cluster is pretty much it.

So here is the procedure that will need to be applied on the cluster (both the sparta Xen hosts, and the node Xen guests)... as an example, I have performed the necessary updates on sparta00 and node00... so these changes will need to be propagated to spartas 01-07 and nodes 01-07.

=====Background reading=====
Some information on this exploit:

  * http://www.thushanfernando.com/index.php/2010/09/20/cve-2010-3081-64bit-linux-kernel-root-exploit/
  * http://security-tracker.debian.org/tracker/CVE-2010-3081
  * My status update in the LAIR: http://lab46.corning-cc.edu/haas/status#linux_64-bit_local_root_exploit

=====Security Experience=====
If you'd like to see the severity of this problem, log on (as your normal DSLAB user), onto one of the cluster nodes that has not been updated yet... download and compile the **robert_you_suck.c** code (link can be found on my status page update), and do the following:

<cli>
node01:~$ id
uid=3XYZ(youruser) gid=3000(dslab) groups=3000(dslab)
node01:~$ gcc -o robert_you_suck robert_you_suck.c
node01:~$ ./robert_you_suck
...
# id
uid=0(root) gid=0(root) groups=0(root)
</cli>

This can be done by any user who has access to the machine. Clearly, this is a problem that needs fixing promptly.

On the other hand, try the same thing on node00 of the cluster.. you will find that you will not get a "#" shell, but it remains the user-level "$" shell... this indicates that the exploit was unsuccessful (thanks to the kernel update).

=====Step 1: Update and upgrade packages (and misc. housecleaning)=====
<cli>
sparta00:~$ sudo aptitude update && aptitude upgrade && aptitude update && aptitude clean
</cli>

and the VM:

<cli>
node00:~$ sudo aptitude update && aptitude upgrade && aptitude update && aptitude clean
</cli>

Answer 'Y' to apply the updates... among them will be a new kernel (or modules, if you're on the Xen guest)... this will contain the necessary fix.

<WRAP round info box>NOTE: BOTH VM and host need to be updated... the VM uses the modules, the host has the kernel.</WRAP>

=====Step 2: shut down the node=====
A reboot is necessary (for both), so we need to shut down the node (the VM) first:

<cli>
node00:~$ sudo shutdown -h now
</cli>

=====Step 3: fix grub config on sparta=====
The kernel update refreshed the grub config file, causing one of our options to disappear.

Edit /etc/grub/menu.lst and, at the bottom of the file, where the boot kernels are listed, should **ONLY** be the following, with the respective options set:

<code>
## ## End Default Options ##

title           Xen 3.2-1-amd64 / Debian GNU/Linux, kernel 2.6.26-2-xen-amd64
root            (hd0,0)
kernel          /boot/xen-3.2-1-amd64.gz dom0_mem=262144
module          /boot/vmlinuz-2.6.26-2-xen-amd64 root=/dev/sda1 ro console=tty0
module          /boot/initrd.img-2.6.26-2-xen-amd64

title           Debian GNU/Linux, kernel 2.6.26-2-amd64
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.26-2-amd64 root=/dev/sda1 ro quiet
initrd          /boot/initrd.img-2.6.26-2-amd64

title           Debian GNU/Linux, kernel 2.6.26-2-amd64 (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.26-2-amd64 root=/dev/sda1 ro single
initrd          /boot/initrd.img-2.6.26-2-amd64

### END DEBIAN AUTOMAGIC KERNELS LIST
</code>

Again, just these are needed.. if you want... delete the stanzas that are there and replace them with this.

=====Step 4: Reboot the sparta=====
<cli>
sparta00:~$ sudo shutdown -r now
</cli>

The sparta (VM host) will reboot. When it comes back up, we can relaunch the VM.

=====Step 5: Launch the node=====
<cli>
sparta00:~$ sudo xm create /xen/conf/node00.cfg
</cli>

After a minute or so, the node will be back up, ready for business. This host/guest pair has been updated!

If you try the exploit on it, you should note that it no longer yields a root shell.