[rsbac] Local root exploit in 2.4.22 and previous
Amon Ott
ao at rsbac.org
Thu Dec 4 09:14:59 CET 2003
On Mittwoch, 3. Dezember 2003 19:05, Fabian Kiendl wrote:
> > there is a local root exploit present in 2.4 kernels up to 2.4.22. The
> > following patch agains mm/mmap.c fixes it (offsets are from an RSBAC and
> > PaX
> > patched kernel, expect offset warning!):
>
> What would have happened if I hadn't installed that patch on an
> RSBAC-enabled system and someone had tried to exploit it? Would RSBAC have
offered me any
> protection against the exploit iself, or would at least have the RC, ACL and
> FF modules successfully have prevented rootkit installation?
AFAIK, the attack used on the Debian Servers
1. Used a local shell (easier to deny with RSBAC, but may be legal)
2. Fetched extra code and the SucKIT rootkit via http (both writing to disk
and access to remote network endpoints can be denied by RSBAC)
3. compiled or downloaded a do_brk exploit program (compiler accessible?)
4. ran the program (execute uncontrolled program)
5. became root through the program (may be a very restricted account with
wrong role etc. with RSBAC)
6. installed the rootkit through /dev/kmem (usually protected as SCD kmem
against all users, including root and secoff)
7. sniffed passwords to connect to other systems (raw network access, can be
denied by RSBAC)
8. repeated the previous steps
So most of the steps taken would have been intercepted and logged by a strict
RSBAC configuration. If you used remote logging, you would certainly have
found some interesting NOT_GRANTED messages before even a successful attack
could have disabled the logging.
However, an attacker with good RSBAC knowledge, who came to step 4 or
exploited a service, might have been able to place a notification call for
CHANGE_OWNER to 400 through the do_brk bug (repeated for several users with
separation of duty), disable access control (some work, if no switching or
softmode allowed, usually produces extra log messages) and then continue.
To summarize, an attack would have required a lot of extra knowledge and work
to break a well configured RSBAC system, it would have produced some
interesting log messages, but it could have been possible to do.
So, please fix your systems or update to 2.4.23 (I just made 2.4.23 support
official).
Additionally, I strongly recommend to protect against buffer overflow exploits
in your server programs to avoid uncontrolled access in the first place.
Personally, I prefer the PaX patch, which is referenced from the link page
and combines well with RSBAC (and which will be configurable via RSBAC in
1.2.3).
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
More information about the rsbac
mailing list