Summary: Mistakes happen. More importantly though, how do you access your machine to clean up after they happen? Yet even more importantly, can you stop unauthorized users from exploiting these same techniques?

Ever accidentally lose the ability to become root on your own system? Perhaps you accidentally changed root's shell to /bin/bish because of a typo when adding that new user. Perhaps you simply forgot what you changed the root password to since you always use sudo. (Sudo == good -- logging in as root == bad.) Or maybe when trying to remove that old /etc.bak directory you hit a space instead of dot. Whoops.

When these mistakes happen, it's nice to know that you have options to get on your machine as root to clean up your mess and I'll show you some of them. When you see how easy they are, you may make the logical (and disturbing realization) that even unauthorized folks can use these same techniques to take over your machine.

All the methods I'm going to talk about here are possible if an attacker has physical access to your machine. With physical access, the baddie has some pretty impressive power. I usually just call this the 'Boot access is Root access' effect.

When your Linux box boots, it generally goes through several stages. First the BIOS [1] gives you a chance to hit F8, F5, or whatever other fun key combo it likes to let you mess with things. It'll probably initialize some hardware, and you'll get a nice text splash screen or two. Eventually, you get to the Lilo prompt. [2]

Most likely you've never spent time at the Lilo (Linux loader) prompt, since it will boot Linux automatically if you don't press a key right away. However, this is your opportunity to tell Linux how it should boot. Say your default kernel is called 'linux' in lilo.conf, but you have an older kernel, say 2.2.15 named linux.old. All a malicious hacker needs do at the console is type:

lilo: linux.old

at the lilo prompt and the older kernel will boot.

Since 2.2.15 has several instant ways for a normal user to become root, the attacker can simply log in (this assumes they have an account, or method of obtaining one) and they'll have root access in seconds.

To prevent someone at the console from booting an alternate kernel you have several options:

Comment out the Alternate Kernel Definitions from /etc/lilo.conf The definition starts with 'image=' and goes until the next 'image=' line (or end of file). For example to make our linux.old kernel unavailable, you'd find the kernel definition, which would look like this:

image=/boot/vmlinuz-2.2.15
	label=linux.old
	read-only
	root=/dev/hda7

Comment these out by putting a '#' at the beginning of the line. When you're done editing the file, run lilo to make the changes:

root# lilo
Added linux *
Added openbsd
root#

Make sure that you don't see 'linux.old' as one of the entries. Whichever is marked with a '*' is the default kernel, the one that will launch if you don't explicitly specify one.

Password Protect the Other Kernel Definitions You simply add a 'password' line to the configuration, such as this:

image=/boot/vmlinuz-2.2.15
	label=linux.old
	password=TalkAboutAnOldKernel
	read-only
	root=/dev/hda7

When attempting to boot the linux.old kernel, lilo will require the password you specify in lilo.conf. I only suggest you do this with old kernels that could be useful at some time and which are hopefully not known to have instant root bugs. All completely unneeded kernels should be removed from lilo.conf, and from your hard drive for that matter.

Again, make sure to re-run lilo when finished.

Next Week: Single User Mode

[1] Yes, I'm being PC centric. Forgive me, fellow non-x86 users. [2] Now I must apologize to all non-lilo users -- I can't win. Other boot loaders have similar security precautions: RTFM.

Bri Hatch is Chief Hacker at Onsight, Inc. and author of Hacking Linux Exposed and Building Linux VPNs. During the writing of HLE, he once had twelve kernels installed and running on his test system at one time, using both User Mode Linux and VMWare. He hopes never to have that many again. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 18-Jun-2002.