Vulnerability Development mailing list archives
Re: Core Dump as an Intrusion Event
From: Michael Wojcik <Michael.Wojcik () MERANT COM>
Date: Fri, 6 Oct 2000 09:05:37 -0700
From: Eclipse, Solar [mailto:solareclipse () PHREEDOM ORG] Sent: Thursday, October 05, 2000 11:23 AM
On Thu, Oct 05, 2000 at 07:00:15AM -0700, Crispin Cowan wrote:[should core dumps from daemons be handled as possible intrusion
events?]
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.
This is a very interesting idea and it needs further research. System services on Linux dump core very rarely and a core dump can indeed be an indication that something is wrong. Keep in mind that core dumps can be disabled and that it's easy to delete any evidence once the attacker has root access. A better solution would be a kernel patch that hooks into the SIGSEGV signal handler and logs all segmentation faults. A predefined list of programs can be monitored. Maybe it's fesable to log segfaults of all root processes.
A data point: in the default configuration, all versions of AIX since 3.1 (and possibly earlier) logged *all* process terminations by default-dump-core signals (SEGV, BUS, etc.), regardless of whether they were running with elevated privileges, actually created a core file, etc. Exit without handling the signal and you get logged. Only basic info (process name, pid, timestamp, user ID, signal name, cwd) was recorded, but that's often enough. This policy never caused excessive logging on any of my systems, including the development ones. I'd definitely recommend trying it, probably in the kernel's process cleanup code - if a process is exiting on any of the signals that normally dump core, log a kern.notice message. The AIX system error logging facility - a proprietary, albeit well-documented, IBM invention rather than syslog, in typical AIX fashion - also has some decent filtering capabilities, including distinct hex identifiers for each message type, which makes it easy to find, say, all the process signal terminations since yesterday. But doing the same with syslog-based logs just means a little grep'ing; if you've got something like swatch, it's just another rule. Michael Wojcik michael.wojcik () merant com MERANT Department of English, Miami University
Current thread:
- Re: Core Dump as an Intrusion Event, (continued)
- 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)
- Re: Core Dump as an Intrusion Event Gigi Sullivan (Oct 11)
- Re: Core Dump as an Intrusion Event antirez (Oct 12)
- Re: Core Dump as an Intrusion Event antirez (Oct 09)
- Re: Core Dump as an Intrusion Event antirez (Oct 09)
- Re: Core Dump as an Intrusion Event Daniel Roesen (Oct 10)