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:
- 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:
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.