[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 
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 

http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

More information about the rsbac mailing list