|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: Core Dump as an Intrusion Event
From: Crist Clark (crist.clark
GLOBALSTAR.COM)Date: Thu Oct 05 2000 - 13:13:49 CDT
- Next message: W. Reilly Cooley: "Re: Core Dump as an Intrusion Event"
- Previous message: Pascal Bouchareine: "Re: Core Dump as an Intrusion Event"
- In reply to: Crispin Cowan: "Core Dump as an Intrusion Event"
- Next in thread: W. Reilly Cooley: "Re: Core Dump as an Intrusion Event"
- Reply: Crist Clark: "Re: Core Dump as an Intrusion Event"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Crispin Cowan wrote:
>
> Background: StackGuard 2.0 (as released this summer) does not provide
> secure resistance to format bugs. However, because StackGuard changes
> some data layouts, it does tend to change the offsets that are required
> to make the exploit work. As a result, exploits tuned for the
> "standard" instance of a vulnerable program tend to just cause the
> victim program to dump core without giving up the shell prompt.
>
> This leads me to conjecture that "core dump" makes a good intrusion
> detection event. Server apps. ("services", e.g. Apache, ftpd, fingerd
> ;-) should not be dumping core, so you could treat a core dump as an
> indication that an attacker is rattling your door. StackGuard enhances
> this effect, by making it unlikely that the first attack attempt will
> work. Other factors may also be used to enhance this effect.
>
> In theory, theory is just like practice, but in practice it's different.
>
> Anyone have practical comments on this hypothesis? In practice, how
> often do services dump core for non-security reasons? If services dump
> core for non-security reasons even just a little, then the
> false-positive rate of intrusion detection from this clue gets out of
> control.
Core dumps are, IMHO, security related events regardless of whether or
not you have Stackguard running for the same reasons you state.
On a "server" machine, i.e. one that has limited access and mostly runs
developed products (your Apache, ftpd, etc.), all core dumps should be
watched carefully.
The problem lies with something like a multi-user development system. If
joeuser is developing code on a box, he could be generating dozens if
not hundreds of core dumps per day. The trick, and I am not aware of a
efficient, fool proof way to do this, is to automate a process where
you can separate core dumps of his apps from the core dumps you might
get if he were trying to figure out how to get some canned exploit on
a system binary to work.
But to reiterate, a core dump from a "server-class" application or
system binary is almost always worth a closer look. Oh, and one small
nit pick, it's really not core dumps we want to be watching for but
segmentation faults, bus errors, and similar conditions. Afterall,
your root-owned processes are not actually creating corefiles, are
they? :)
-- Crist J. Clark Network Security Engineer crist.clarkglobalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926
- Next message: W. Reilly Cooley: "Re: Core Dump as an Intrusion Event"
- Previous message: Pascal Bouchareine: "Re: Core Dump as an Intrusion Event"
- In reply to: Crispin Cowan: "Core Dump as an Intrusion Event"
- Next in thread: W. Reilly Cooley: "Re: Core Dump as an Intrusion Event"
- Reply: Crist Clark: "Re: Core Dump as an Intrusion Event"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]