Re: Secure 2.4.x kernel
On Fri, Dec 21, 2001 at 03:25:04PM -0500, Gary MacDougall wrote: > Hmmm I don't buy that this *couldn't* be done on the Intel. > I might be overstepping my knowledge, but I'm sure there > *must* be a way. The first method that comes to mind is making the stack segment non-executable. IIRC, this is not supported by the x86. It's a real shame, because that would immediately stop about 99.9% of all buffer overrun exploits. -- Absurdity, n.: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce, "The Devil's Dictionary"
Re: Party with porn stars
>http://codesorcery.net/docs/spamtricks.html How does Spamassassin compare to Junkfilter, if anyone has used Junkfilter. Junkfilter is very good, but I am finding that more spam is getting through these days. -- Andrew
kernel-modul compile/install
hello list,
A question with a security aspect and a genral programming:
today I tryes to compile and install the StMichael kernel module:
StMichael is a LKM that attempts to detect and divert attempts to install a
kernel-module backdoor into a running linux system. This is done by
monitoring the init_module and delete_module process for changes in the
system call table. Detects most modern LKM's, including KIS. Changes: Fixed
a serious bug that could cause a kernel Oops if StMichael was not the
first module loaded into the system. Homepage:
http://www.sourceforge.net/projects/stjude. By Tim Lawless
I get it compiled, but coud't load it. So I tryes a real Simple one let us
call it lkm.c youst to see how kernelmodules work.
http://www.linuxdoc.org/LDP/lkmpg/mpg.html ...
---8<--
//#define MODULE
#include
#include
#include
int init_module(void) { printk("<1>Hello World\n"); return 0; }
void cleanup_module(void) { printk("<1>Bye, Bye"); }
---8<--
youst a small kenel modul from a tutorial, I compile it with:
gcc-3.0 -Wall -DMODULE -D__KERNEL__ -DLINUX -c lkm.c
-I/usr/src/kernel-headers-2.4.12-686/include/
or:
gcc-2.95 -Wall -DMODULE -D__KERNEL__ -DLINUX -c lkm.c
-I/usr/src/kernel-headers-2.4.12-686/include/
Whenn I try to insmod it, Nothing youst this output:
#insmod lkm.o
Warning: loading lkm.o will taint the kernel: no license
Segmentation fault
in the /var/log/mesages I found:
.Dec 22 17:35:15 ingwer kernel: <1>Unable to handle kernel NULL pointer
.dereference at virtual address
Dec 22 17:35:15 ingwer kernel: printing eip:
Dec 22 17:35:15 ingwer kernel:
Dec 22 17:35:15 ingwer kernel: Oops:
Dec 22 17:35:15 ingwer kernel: CPU:0
Dec 22 17:35:15 ingwer kernel: EIP:0010:[<>]Tainted: P
Dec 22 17:35:15 ingwer kernel: EFLAGS: 00010293
Dec 22 17:35:15 ingwer kernel: eax: ebx: 000a ecx:
edx: 4001600a
Dec 22 17:35:15 ingwer kernel: esi: 40016000 edi: ebp: c339bf9c
esp: c339bf70
Dec 22 17:35:15 ingwer kernel: ds: 0018 es: 0018 ss: 0018
Dec 22 17:35:15 ingwer kernel: Process insmod (pid: 1090, stackpage=c339b000)
Dec 22 17:35:15 ingwer kernel: Stack: cc89114c 40016000
c339bfa4 0150 0805f640
Dec 22 17:35:15 ingwer kernel: c01347f3 c339bfa4 c339bfbc
cc8908d3 c339a000 0805f640 bfffab3c
Dec 22 17:35:15 ingwer kernel:cbaca000 c1306360 c0106e1c bfffea6c
c0106d2b 0805f640 0150 bfffea6c
Dec 22 17:35:15 ingwer kernel: Call Trace: [sys_stat64+103/116]
[error_code+52/60] [system_call+51/56]
Dec 22 17:35:15 ingwer kernel:
Dec 22 17:35:15 ingwer kernel: Code: Bad EIP value.
My kernel #uname -a
Linux ingwer 2.4.12-686 #2 Sat Oct 13 20:13:05 EST 2001 i686 unknown
coud managed kenel modules, I built it my own. This are the first
kernelmodules I build , StMichel came with a configure script , for lkm.c I
cut and paste the compiler instructions. None is working.
So where coud I find hints, or anybody an Idear what I make wrong???
thanks ingo
Re: Secure 2.4.x kernel
On Fri, Dec 21, 2001 at 03:25:04PM -0500, Gary MacDougall wrote: > Hmmm I don't buy that this *couldn't* be done on the Intel. > I might be overstepping my knowledge, but I'm sure there > *must* be a way. The first method that comes to mind is making the stack segment non-executable. IIRC, this is not supported by the x86. It's a real shame, because that would immediately stop about 99.9% of all buffer overrun exploits. -- Absurdity, n.: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce, "The Devil's Dictionary" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Party with porn stars
> > http://codesorcery.net/docs/spamtricks.html How does Spamassassin compare to Junkfilter, if anyone has used Junkfilter. Junkfilter is very good, but I am finding that more spam is getting through these days. -- Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel-modul compile/install
hello list,
A question with a security aspect and a genral programming:
today I tryes to compile and install the StMichael kernel module:
StMichael is a LKM that attempts to detect and divert attempts to install a
kernel-module backdoor into a running linux system. This is done by
monitoring the init_module and delete_module process for changes in the
system call table. Detects most modern LKM's, including KIS. Changes: Fixed
a serious bug that could cause a kernel Oops if StMichael was not the
first module loaded into the system. Homepage:
http://www.sourceforge.net/projects/stjude. By Tim Lawless
I get it compiled, but coud't load it. So I tryes a real Simple one let us
call it lkm.c youst to see how kernelmodules work.
http://www.linuxdoc.org/LDP/lkmpg/mpg.html ...
---8<--
//#define MODULE
#include
#include
#include
int init_module(void) { printk("<1>Hello World\n"); return 0; }
void cleanup_module(void) { printk("<1>Bye, Bye"); }
---8<--
youst a small kenel modul from a tutorial, I compile it with:
gcc-3.0 -Wall -DMODULE -D__KERNEL__ -DLINUX -c lkm.c
-I/usr/src/kernel-headers-2.4.12-686/include/
or:
gcc-2.95 -Wall -DMODULE -D__KERNEL__ -DLINUX -c lkm.c
-I/usr/src/kernel-headers-2.4.12-686/include/
Whenn I try to insmod it, Nothing youst this output:
#insmod lkm.o
Warning: loading lkm.o will taint the kernel: no license
Segmentation fault
in the /var/log/mesages I found:
.Dec 22 17:35:15 ingwer kernel: <1>Unable to handle kernel NULL pointer
.dereference at virtual address
Dec 22 17:35:15 ingwer kernel: printing eip:
Dec 22 17:35:15 ingwer kernel:
Dec 22 17:35:15 ingwer kernel: Oops:
Dec 22 17:35:15 ingwer kernel: CPU:0
Dec 22 17:35:15 ingwer kernel: EIP:0010:[<>]Tainted: P
Dec 22 17:35:15 ingwer kernel: EFLAGS: 00010293
Dec 22 17:35:15 ingwer kernel: eax: ebx: 000a ecx:
edx: 4001600a
Dec 22 17:35:15 ingwer kernel: esi: 40016000 edi: ebp: c339bf9c
esp: c339bf70
Dec 22 17:35:15 ingwer kernel: ds: 0018 es: 0018 ss: 0018
Dec 22 17:35:15 ingwer kernel: Process insmod (pid: 1090, stackpage=c339b000)
Dec 22 17:35:15 ingwer kernel: Stack: cc89114c 40016000
c339bfa4 0150 0805f640
Dec 22 17:35:15 ingwer kernel: c01347f3 c339bfa4 c339bfbc
cc8908d3 c339a000 0805f640 bfffab3c
Dec 22 17:35:15 ingwer kernel:cbaca000 c1306360 c0106e1c bfffea6c
c0106d2b 0805f640 0150 bfffea6c
Dec 22 17:35:15 ingwer kernel: Call Trace: [sys_stat64+103/116]
[error_code+52/60] [system_call+51/56]
Dec 22 17:35:15 ingwer kernel:
Dec 22 17:35:15 ingwer kernel: Code: Bad EIP value.
My kernel #uname -a
Linux ingwer 2.4.12-686 #2 Sat Oct 13 20:13:05 EST 2001 i686 unknown
coud managed kenel modules, I built it my own. This are the first
kernelmodules I build , StMichel came with a configure script , for lkm.c I
cut and paste the compiler instructions. None is working.
So where coud I find hints, or anybody an Idear what I make wrong???
thanks ingo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Secure 2.4.x kernel
Well hello list, it could be, that i'm overstepping my knowledge (and my english). If i have well understood, one of the problems of bufferoverruns is the follwing: The assembly statement "jsr" (jump to subroutine) puts the return address on the same stack, where space for local variables is reserved. So one solution is to seperate these stacks. So it's more a "problem" of the C-Compiler (and the number of Address-Register of the CPU and memory). So my questions are : 1) Is my problem description right ? 2) On other plattforms (for example on the newer plattforms like ia64) are there seperate stacks ? 3) Why is this not done on the "0x86"-Plattform ? (Historical Reasons ? No chance of a step by step migration because of the interplay between programms and libarys ?) On Fri, 21 Dec 2001, Kelly Martin wrote: > > Hmmm I don't buy that this *couldn't* be done on the Intel. > > I might be overstepping my knowledge, but I'm sure there > > *must* be a way. > > > Going back to my 68k days, it would have been fairly easy > > to write this. Hey, I'm not an Intel assembly/opcode expert, > > but it seems to me, I think that you could sit something right > > in on an interrupt that would alert when a fork/exec call > > was being made -- it wouldn't take a rocket scientist to > > figure out that if you could take an interrupt/event on > > this type of sig, you could certainly redirect the behavior > > or outcome. > > You've misunderstood. I was stating that it would be hard to _protect the > stack against overruns_ on the Intel platform. What you're talking about > has nothing to do stack protection. Fork and exec (being syscalls) are > already handled as software interrupts, so what you're talking about doing > is what the kernel already does. > > > The examples pointed out (electric fence, st. james etc.) are > > fine "workarounds", but they all look a little too "patch-like" > > for it to be something that is "industrial strength". > > I just think that intercepting the syscalls like fork and exec > > at the kernel level for anything that is not "privy" should > > be a feature of the kernel. > > Statements like this lead me to question whether you really know what you're > talking about. Electric Fence is a tool for debugging heap overruns and has > nothing to do with access control in the kernel. St. Jude is _exactly_ what > you're claiming is necessary: it's a tool for intercepting syscalls at the > kernel level. And, to be honest, where the hell else would you intercept a > syscall? > > Kelly > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
RE: Secure 2.4.x kernel
Well hello list, it could be, that i'm overstepping my knowledge (and my english). If i have well understood, one of the problems of bufferoverruns is the follwing: The assembly statement "jsr" (jump to subroutine) puts the return address on the same stack, where space for local variables is reserved. So one solution is to seperate these stacks. So it's more a "problem" of the C-Compiler (and the number of Address-Register of the CPU and memory). So my questions are : 1) Is my problem description right ? 2) On other plattforms (for example on the newer plattforms like ia64) are there seperate stacks ? 3) Why is this not done on the "0x86"-Plattform ? (Historical Reasons ? No chance of a step by step migration because of the interplay between programms and libarys ?) On Fri, 21 Dec 2001, Kelly Martin wrote: > > Hmmm I don't buy that this *couldn't* be done on the Intel. > > I might be overstepping my knowledge, but I'm sure there > > *must* be a way. > > > Going back to my 68k days, it would have been fairly easy > > to write this. Hey, I'm not an Intel assembly/opcode expert, > > but it seems to me, I think that you could sit something right > > in on an interrupt that would alert when a fork/exec call > > was being made -- it wouldn't take a rocket scientist to > > figure out that if you could take an interrupt/event on > > this type of sig, you could certainly redirect the behavior > > or outcome. > > You've misunderstood. I was stating that it would be hard to _protect the > stack against overruns_ on the Intel platform. What you're talking about > has nothing to do stack protection. Fork and exec (being syscalls) are > already handled as software interrupts, so what you're talking about doing > is what the kernel already does. > > > The examples pointed out (electric fence, st. james etc.) are > > fine "workarounds", but they all look a little too "patch-like" > > for it to be something that is "industrial strength". > > I just think that intercepting the syscalls like fork and exec > > at the kernel level for anything that is not "privy" should > > be a feature of the kernel. > > Statements like this lead me to question whether you really know what you're > talking about. Electric Fence is a tool for debugging heap overruns and has > nothing to do with access control in the kernel. St. Jude is _exactly_ what > you're claiming is necessary: it's a tool for intercepting syscalls at the > kernel level. And, to be honest, where the hell else would you intercept a > syscall? > > Kelly > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
