[rsbac] Local root exploit in 2.4.22 and previous

[Amon Ott]

On Donnerstag, 4. Dezember 2003 09:52, Thorsten Sauter wrote:
> * Amon Ott <rsbac at rsbac.org> [2003-12-04 09:14]:
> | AFAIK, the attack used on the Debian Servers
> | 1. Used a local shell (easier to deny with RSBAC, but may be legal)
> 
> why the user needs a login account, if he/she can't execute a valid
> shell?

You can open a shell without a login account, e.g. through an exploited 
service. RSBAC can be used to avoid this. In the Debian case, the attacker 
used an official account.
 
> | 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)
> 
> well, this sounds a little bit like "ifconfig eth0 down". I think you
> can't do this on a machine for working purpose.

This was not what I wanted to express - even the attacker needs the network.

With RSBAC network templates, you can specify exactly who may access what 
network ressource without making network unusable. If a user does not need 
outgoing network access (to port 80 on non-local IPs or whatever), this can 
be denied. This user can still work on the local system and within the local 
network.

> | 3. compiled or downloaded a do_brk exploit program (compiler accessible?)
> 
> this exploit only runs on i386? I guess most of us has a i386 machine,
> which can compile the code localy. This means removing the compile
> doesn't really help here.

Never said that, do_brk is common code for all archs. The exploit should also 
work on other archs, but not on all - some archs access kernel memory 
differently.

If you compile on another system, you need a way to transfer the code to the 
server, which is basically not much different to a download.

> | 4. ran the program (execute uncontrolled program)
> 
> ok. this sounds good. RC model for all binaries in /bin,/sbin,...

This is the main defence line against most attacks. An expert attacker could 
execute all code from within a running service, though.
 
> | 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.
> 
> really hard

I cannot tell how the notification call could have been placed, without REG 
support the function address is not even exported as a symbol. The internal 
data structure position might have been guessed, because the list header 
contains the list name.

But, wow, you would need a lot of determination. :)
 
> | So, please fix your systems or update to 2.4.23 (I just made 2.4.23 
support 
> | official).
> 
> of course.

And when you did, please report any bugs...

The first has already been reported: bugfix 1.2.2-4 breaks reg_sample2. Please 
disable REG sample module compilation, or remove this sample from rsbac/adf/
reg/makefile.

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