Linux lilo vulnerabilities

On most Linux systems root can be obtained with the LD_PRELOAD
environment variable:

1) Download the hacked libc.so.5 that spawns a shell when a call
   is made to crypt from http://www.rootshell.com and put it
   in a directory that you can remember like ->  /var/tmp

2) Reboot the machine and when you see the LILO prompt, 
   hit the SHIFT key and at the LILO boot:  prompt type something like:
   LILO boot: linux LD_PRELOAD=/var/tmp/libc.so.5

3) When the Linux system boots, you might see a lot of warnings
   and errors - Just ignore them...

4) When you will get to a login prompt,

   ->If you are using Red Hat Linux, you *must*
   log in as a normal user and supply as correct password.

   ->If you are using Slackware Linux, you can
   type in a few random characters for the login and password.

5) At this point, you are now root.


			- BeastMaster V



=======================================================================

	This method is even easier than the one above

ok, i found the easiest way to change a root passwd on a physically
accessed machine is to apply the boot params "init=/bin/bash rw"
 
ie if you use lilo, and your image is "linux" try
linux init=/bin/bash rw

this should drop you to a root shell.  just edit your passwd file. 
and run "sync" before you reboot.

=======================================================================

Date: Thu, 28 Aug 1997 13:33:07 -0500 (CDT)
From: John Goerzen 
To: linux-security@redhat.com
Subject: [linux-security] Root vulnerabilities in Linux

[mod: If you're alergic to old problems, especially ones that have
simple solutions, you can skip the rest. A certain audience of
Linux-security DOES want to see this kind of re-run. -- REW]


[ Posted to linux-security, bugtraq, debian-security ]

For linux machines in situations where users have physical access (such as
University labs as is the case in this situation), there are some
vulnerabilities that can allow users to get root even if other precautions
have been taken (disabling floppy drive, locking case shut, etc).

There are three problems:

1: Boot to single user mode
2: Specifify alternate init program
3: Specify alternate root partition

All three rely on passing parameters to LILO on boot.

I'll explain them each in detail and then talk about fixes.

Problem 1: Booting to single-user mode

This problem exists on at least RedHat.  Debian is not vulnerable to this
problem, as discussed below.

One can type the following to LILO and get a root shell:

Linux 1
Linux emergency

This is due to a problem in the /etc/inittab file.  Debian fixes this by
doing:

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

NOTE: I haven't checked it out, but the other escapes to single-user mode
in RedHat may be an issue too (for instance, if a fsck fails)

Proglem 2: Using an alternate init program
(Originally discussed on the Linux kernel developer's list and pointed out
to me by David Gitchell)

One can say to LILO:

Linux init=/bin/bash

And they will get a root shell immediately.  This is an obvious problem.

Problem 3: Specifying an alternate root partition
(Originally mentioned by Bruce Perens)

One can set the root filesystem to point to a different filesystem other
than the default.  This is somewhat less of a problem since a root
filesystem must have a certain structure to be useful to an attacker;
however, systems with a /tmp *filesystem* (a separate filesystem, not a
directory) could be vulnerable to attacks using this method.

------------
Fixes
------------

Ideally, Linux would adobt a boot loader mechanism similar to that used by
FreeBSD wherein LILO would only load the kernel and the kernel itself
prompts for information (and could be configured to not accept certain
info).  Seeing that this is unlikely to happen, however:

A workaround can be achieved by using PASSWORD and RESTRICT options in
/etc/lilo.conf.

NOTE:  You MUST set your /etc/lilo.conf to mode 0600 and owner root.root;
otherwise everyone on the system will be able to get your LILO password!

Alternatively, to bypass the problem altogether, one could elect to boot
the kernel directly without any kind of loader (this usually works best
with a floppy disk but could be done on a hard drive as well)  While this
is probably the most effective solution, it only works in certain
situations (those where the kernel never needs any command-line
parameters).

John Goerzen