[2195] in linux-security and linux-alert archive
[linux-security] Re: You got some 'splaininn to do Lucy ;-)
daemon@ATHENA.MIT.EDU (Erik Espinoza)
Mon Aug 2 03:02:42 1999
Date: Sat, 31 Jul 1999 08:44:30 -0700
To: macker <macker@netmagic.net>
From: Erik Espinoza <espinoza@thecity.sfsu.edu>
Cc: linux-security@redhat.com
In-Reply-To: <Pine.LNX.3.96.990731005545.17214C-100000@shell.netmagic.ne
t>
Resent-From: linux-security@redhat.com
Resent-Reply-To: linux-security@redhat.com
Compiling your setuid root programs (or programs that run as root) with
stackguard and using the Solar Design secure-linux patch can greatly add to
your system. Making buffer overflows extremely hard, if possible, to do.
That combined with tripwire can be a hard to beat solution. Caveat: Solar
Design's patch only works with latest 2.0.x kernel.
At 12:59 AM 7/31/99 -0700, you wrote:
>On Sat, 31 Jul 1999, Crispin Cowan wrote:
>
> > John Summerfield wrote:
> >
> > > Without an audit trail, how would you know?
> > >
> > > Some versions of BIND had a bug allowed hackers root access. Other than
> > > BIND mysteriously crashing, you'd never know it happened. Someone could
> > > have made of with a copy of some sensitive information without you every
> > > knowing it had been accessed: with an audit trail, you might at least
> > > discover it had been read by someone who shouldn't.
> >
> > While it is true that you need *some* kind of host-based intrusion
> detection to
> > know that your host has been secure, it is not true that you need
> Orange Book
> > Auditing[tm] to do intrusion detection. Counter-example: if you used
> Tripwire
> > to periodically check the integrity of your host, then you could detect
> > intrusions without Orange Book style auditing.
> >
> > Caveat: I mean use Tripwire *properly*. Don't bother whining about
> the myriad
> > ways it can be used improperly, that's not the point :-)
> >
> > Crispin
>[snip]
>
>Tripwire, while very useful, can detect a *changed* filed that's being
>monitored, how would it detect a passive intrusion? Most buffer
>overflows, the bind remote exploit being no exception, simply spawn a
>setuid root shell. This is one that's running, not one in /tmp or
>otherwise. In fact, no files would be created or modified (that i'm aware
>of).
>
>Now, if someone tried to backdoor the system, then tripwire (as well as a
>check using find for setuid bins) would be quite effective...
>
>Judging by the "new mail" indicator, I think John is about to say
>something to the effect of what i'm sending now...
>
>*clink clink*
>
>-macker
>
>--
>----------------------------------------------------------------------
>Please refer to the information about this list as well as general
>information about Linux security at http://www.aoy.com/Linux/Security.
>----------------------------------------------------------------------
>
>To unsubscribe:
> mail -s unsubscribe linux-security-request@redhat.com < /dev/null
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe linux-security-request@redhat.com < /dev/null
