It wasn’t a good weekend for Linux.
The ultraportable ASUS Eee PC has seen quite a bit of publicity lately. With prices starting as low as $300, it’s about as cheap as laptops get, and runs on a solid-state drive instead of a hard disk. Of course, to get such a low price, it doesn’t ship with Windows on it — instead, it has a customized version of Xandros Linux using IceWM with a host of open-source applications, like OpenOffice, Firefox, etc. Xandros is a Debian derivative, so the apt package system can be used to get almost any popular Linux application.
Linux gets a lot of good press for being “secure”, by which the media usually means “free from viruses and spyware.” This is pretty much true, for the simple reason that it’s not worth anyone’s time to write a virus for Linux when the market share is so low. However, there’s a big difference between “free of malware” and “secure by default.” It turns out that the Xandros Linux on the Eee ships with Samba 3.0.24, which dates back to February ’07. (Samba is the Linux version of the SMB protocol — it’s the package that lets Linux machines participate in Windows networks, both to be able to connect to Windows fileshares & to share files themselves.) Samba is, of course, installed and on by default — it wouldn’t be “easy to use” if you had to manually start Samba, would it?
Samba 3.0.24, unsurprisingly considering its age, has known critical security flaws. One of these is a remote root exploit published by RISE Security; the result of this is that any Eee PC can be remotely and silently compromised with a simple Metasploit plugin. If you’re on the Internet with an Eee, anyone can take remote control of your computer, access and change files, etc. You don’t need viruses and spyware when you have direct control.
If you do have an Eee, I suggest using apt to update Samba immediately. Assuming the Eee works like every other Debian derivative out there, a simple “sudo apt-get upgrade samba” ought to take care of the problem.
However, it gets worse. That vulnerability only affects people running an old version of Samba — it only gets attention because a brand-new PC is shipping with said old version of Samba. Also this last weekend, milw0rm released a local root exploit for all Linux kernels 2.6.17 through 220.127.116.11 (the current kernel.) This affects basically every Linux 2.6 system out there, as it affects kernels from June ’06 through today. Since upgrading a kernel is somewhat of an ordeal (it requires taking the system down at the very least, and on many flavors of Linux involves some work besides; Ubuntu makes it quite easy if you’re using the default kernel, though), it’ll be months before many of these machines are upgraded.
It’s a local root exploit, so you have to be logged onto the machine to use it. Obviously, for Linux-based desktops and laptops that isn’t much of a concern; if someone’s sitting at your computer, they can take it over no matter what you do. However, where this gets scary is shared web hosting. Most small web sites are on shared servers; many (even hundreds) of sites on the same box. What’s more, a web hosting company may have all of their various servers trusting each other in such a way that having root on any one means having full control of all of them.
If you have a shell account on a Linux 2.6 box, full control is now as easy as pasting this code into a file on the machine, and typing
cc -static -Wno-format vmsplice-exploit.c
Presto! Root shell. Most web hosts don’t give you shell anymore (unfortunate, in my opinion, and the main reason I’m on DreamHost), but that doesn’t matter — you could upload the source via FTP, along with a simple PHP page that builds it, runs it, and has it send you a shell. There are a lot of hosts on the Internet vulnerable to this right now. (Interestingly, DreamHost is not, as its servers are using the Linux 2.4 kernel instead of the 2.6 branch, and thus lack support for vmsplice.)
Unfortunately, I don’t have enough Linux kernel experience to know exactly what this exploit does to discuss it further — I’ve only done kernel-mode work on Windows, with my Linux coding being strictly in userland. However, vmsplice provides user-mode code with control over a kernel buffer, so any number of tiny bugs could have resulted in a catastrophic compromise (like this one.) Linux Torvalds has an email about splice() here, which does a great job explaining how splice() and vmsplice() can be used to move data around in a copy-free manner through a kernel buffer, but nothing much about why you would do such a thing.
So what to do about this one? There are three choices:
- If you’re running a Linux 2.4 kernel, or anything predating 2.6.17, you’re safe. Well, you’re safe from this; there are other security bugs in year-old kernels.
- Upgrade to a kernel post-18.104.22.168. If you happen to run a cutting-edge distribution like Gentoo, you can just sync the tree today, rebuild the kernel, and be good to go. And if you’re running Gentoo, you actually know how to do that. Debian Stable also has an apt package with a 2.6.18.dfsg.1-18etch1 kernel that’s safe.
- There are some workarounds (hacks, really) on this thread. Note that disabling vmsplice, while it will fix this vulnerability, means crippling a Linux syscall; while this syscall is used only rarely, if you do this and software does try to use vmsplice it may corrupt kernel memory. Thus, option #2 is much, much better; get an updated kernel for your distro that fixes the bug.