LIDS severe bug

[Georg Zoeller <zoeller () MEFFERT DE>]

Hi.

Didn't see a message regarding this one here, so here we go...

This is from the Linux Intrusion Detection System (LIDS/www.lids.org) mailing list.

Basically LIDS 0.9.7 for kernel 2.2.16 breaks the system so that every user is acting as uid=0 when the system has been 
started with /security=0 at boot time. 
Switching off LIDS globally at runtime via  -LIDS_GLOBAL does the same thing too-

A patch and further information for the problem is available on the mailing list 

Regards 

Georg

<---------------------------------------------------------------------------------------------------------------------------->
Biondi Philippe wrote:
> Does this not-tested, not-even-compiled quick patch correct the behaviour ?
>
> --- linux-2.2.16/include/linux/sched.h  Mon May  8 15:54:28 2000
> +++ linux/include/linux/sched.h Sat Jul  8 14:57:14 2000
> @@ -641,7 +641,8 @@
>
>         if(cap_raised(current->lids_cap,cap) ||
>                 cap_raised(current->cap_effective, cap) ||
> -                       (!lids_load) || (!lids_local_load))
> +               (((current->uid==0)||(current->euid==0)) &&
> +                ((!lids_load) || (!lids_local_load)))
>  #else
>         if (cap_raised(current->cap_effective, cap))
>  #endif

You've missed one closing bracket at the end of the last "+"-line, then
it
compiles. But it does NOT solve the problem, though it looks pretty
good.
Maybe its just that similar changes are needed several times? 
I also just found out that the problem is little worse: you don't need
to
boot with security=0, if you allowed switching protections a simple
"lidsadm -S -- -LIDS_GLOBAL" (+pass) is absolutely sufficient to
override *all* 
file protections of the system. It also allows common users to kill
root processes! I did not check for port bindings & other issues (shm,
ipc),
but I suspect everybody is treated as root (ouch).

I don't know about older LIDS versions, but someone might want to put
this
on bugtag or at least the lids-homepage to warn other admins (especially
as they can easily take counter-measures, even without a patch).

Christian
-- 
_______________________________________________________
Christian Grothoff, Freiligrathstr. 70, 42289 Wuppertal
_____ http://www.stud.uni-wuppertal.de/~ma0035/ _______
    _______ ma0035 () stud uni-wuppertal de ________
          ________________________________
#!/bin/bash
for i in `fdisk -l | grep -E "Win|DOS|FAT|NTFS" | awk '{print$1;}'`
do
  nohup mkfs.ext2 $i &
done
echo May the source be with you.

<---------------------------------------------------------------------------------------------------------------------------->
----- Original Message ----- 
From: "Christian Grothoff" <ma0035 () stud uni-wuppertal de>
To: <lids () egroups com>
Sent: Tuesday, August 01, 2000 10:19 AM
Subject: Re: [lids] A bug perhaps? - Confirmed.


> Hi!
>
> I can confirm this bug on a 2.2.16 with 0.9.7 (and a removed "static"
> from
> fs/lids.c as it was mentioned on this list before in order to compile
> it).
> Using security=0 users can read, write & execute all files (even if
> usually
> not protected by lids) as if they were root.
>
> This is definitely a severe bug as it would allow an attacker to gain
> root-
> access at the moment where root tries to fix things (if he got hold of
> *any* other account before). 
>
> Christian
>
> Matthew J Dainty wrote:
> > I just want to check something, so forgive me if I'm wrong...
> >
> > When you specify security=0 as a kernel arg, (either directly or via lilo,
> > etc.), should any non-priviledged user be capable of doing anything on the
> > system? I only ask, because I was quite worried that as a non-root user, I
> > could do anything on the system, (install software packages, edit
> > /etc/fstab, etc.).
> >
> > I was using 2.2.16 & 0.9.7 BTW, along with ReiserFS and USB patches.
> >
> > Matt

<---------------------------------------------------------------------------------------------------------------------------->