OSEC

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: Michael Wojcik (Michael.WojcikMERANT.COM)
Date: Fri Oct 06 2000 - 11:05:37 CDT

> From: Eclipse, Solar [mailto:solareclipsePHREEDOM.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.wojcikmerant.com
MERANT
Department of English, Miami University