Vulnerability Development mailing list archives
Re: Core Dump as an Intrusion Event
From: Crist Clark <crist.clark () GLOBALSTAR COM>
Date: Thu, 5 Oct 2000 11:13:49 -0700
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.clark () globalstar com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926
Current thread:
- Core Dump as an Intrusion Event Crispin Cowan (Oct 05)
- Re: Core Dump as an Intrusion Event Alexander Kiwerski (Oct 05)
- Re: Core Dump as an Intrusion Event antirez (Oct 05)
- Re: Core Dump as an Intrusion Event Slawek (Oct 05)
- Re: Core Dump as an Intrusion Event Pascal Bouchareine (Oct 05)
- Re: Core Dump as an Intrusion Event Crist Clark (Oct 05)
- Re: Core Dump as an Intrusion Event W. Reilly Cooley (Oct 05)
- Re: Core Dump as an Intrusion Event Eclipse, Solar (Oct 05)
- Re: Core Dump as an Intrusion Event Erik Tayler (Oct 06)
- Re: Core Dump as an Intrusion Event Jarno Huuskonen (Oct 06)
- Re: Core Dump as an Intrusion Event Crist Clark (Oct 07)
- Re: Core Dump as an Intrusion Event Kev (Oct 07)
- Re: Core Dump as an Intrusion Event antirez (Oct 08)
- Re: Core Dump as an Intrusion Event Jarno Huuskonen (Oct 08)
- Re: Core Dump as an Intrusion Event Gigi Sullivan (Oct 09)
- Re: Core Dump as an Intrusion Event Jarno Huuskonen (Oct 09)