Table of Contents

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:

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:

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)

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)

sparta00:~$ sudo aptitude update && aptitude upgrade && aptitude update && aptitude clean

and the VM:

node00:~$ sudo aptitude update && aptitude upgrade && aptitude update && aptitude clean

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.

NOTE: BOTH VM and host need to be updated… the VM uses the modules, the host has the kernel.

Step 2: shut down the node

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

node00:~$ sudo shutdown -h now

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:

## ## 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

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

Step 4: Reboot the sparta

sparta00:~$ sudo shutdown -r now

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

Step 5: Launch the node

sparta00:~$ sudo xm create /xen/conf/node00.cfg

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.