[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Secure 2.4.x kernel

> On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
> > Wouldn't it be nice to be able to run the kernel in "secure mode"?
> > I'm curious to know if we could limit the amount of "root exploits"
> > by this method, it would REALLY harden up security on a
> > Linux box... anyone have any opinions on that?
> No, it wouldn't, at least from someone who is determined to hack 
> your box in particular (as opposed to a script kiddy who just 
> wants zombies). Script kiddies for the most part can be stopped 
> fairly easily by making their rootkit fail. Examples:
> o Mount filesystems read-only.
> o Make disks physically read-only [e.g., CD-ROM]
> o apt-get remove gcc
> and, most important:
> o apt-get update && apt-get upgrade
> Remember, exec'ing a shell is just convenient; no reason you 
> can't, for example, just make normal syscalls like 
> open/close/read/write to do your dirty work. I'm sure, given 
> enough time attacking, you could manage to malloc enough memory 
> to upload bash/csh/tcsh/ksh/etc. and then execute it without 
> even touching the exec syscall.

No, actually, if you read my previous messages, I proposed that the
kernel protect against "buffer overruns" by limiting or restricting the
event *after* the overrun occurs.
Someone said that St. Jude was what I was looking for, and I think
its pretty much *exactly* what I was pointing out.

> The problem you're trying to solve is to get the kernel to 
> refuse to execute exploit code. Exploit code looks just like any 
> other code to CPU. Good luck trying to get the kernel to tell 
> the difference.

The problem really isn't the code that an exploit executes, the problem
is that the exploit can allow for "root" access by allowing the malicious
code to spawn a new shell.

> In short: Would EPERM from exec stop a script kiddie? Probably. 
> Would it stop a dedicated attacker? No.

Ok, maybe i'm missing something, but a "script kiddie" basically needs
access to your box to trojan it right?  An attacker, needs access to the
box to attack it, right? Whats the difference?

I don't see the difference.  A "dedicated attacker" in my mind is probably
someone who wants to take ownership of the box and do malicious stuff.
A script kiddie wants to pretty much plant a trojan to have access to the
box whenever they want... whats the difference?


Reply to: