Vulnerability Development mailing list archives
Re: Core Dump as an Intrusion Event
From: Gigi Sullivan <sullivan () SIKUREZZA ORG>
Date: Mon, 9 Oct 2000 21:44:13 +0200
Aiee :) Hello! On Sun, Oct 08, 2000 at 10:41:05PM +0300, Jarno Huuskonen wrote:
On Sun, Oct 08, antirez wrote:This is an example: --- /usr/src/linux/kernel/signal.c Sat Oct 7 23:35:17 2000 +++ /usr/src/linux-2/kernel/signal.c Sat Oct 7 23:44:25 2000 @@ -282,6 +282,10 @@ goto out_nolock; } + if (sig == SIGSEGV) + printk(KERN_NOTICE "%s(pid:%d) segmentation fault\n", + current->comm, current->pid); + switch (sig) { case SIGKILL: case SIGCONT: /* Wake up the process if stopped. */
[snip]
What about adding some code so it can be controlled thru the proc filesystem ? Like enabling/disabling logging, log only certain programs etc. (echo 1 > /proc/sys/kernel/core-logging) Does this sound feasible/sensible ?
This should be usefull, but making this feature sysctl tunable, may allow some malicious attacker to turn off this easly. Ok, if you're root, you can do anything you want, but remember that being root is really different from owning the kernel. Someone could argue that whenever root is owned, log could be altered. This is true and false ;) IMHO. Think about external logging peripherics, secure syslog implementation (CORE SDI one), tripwire or something else ... So, /proc (sysctl) tunable option could be *really* usefull, but hard coded statements are safer, IMHO (even if more restrictive). Nevertheless to say that we could think about a `secure' sysctl tuning mechanims.
-Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen () uku fi University of Kuopio - Computer Centre | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169
bye bye -- gg sullivan -- Lorenzo Cavallaro `Gigi Sullivan' <sullivan () sikurezza org> LibRNet Project Home Page: http://www.sikurezza.org/sullivan LibRNet Mailing List: librnet-subscribe () egroups com Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner)
Current thread:
- Re: Core Dump as an Intrusion Event, (continued)
- 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)
- 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)