Re: Secure 2.4.x kernel
On Monday, December 24, 2001, at 10:52 , Gary MacDougall wrote:
Someone said that St. Jude was what I was looking for, and I think
its pretty much *exactly* what I was pointing out.
Can't, in general, stop an attack. All the attacker has to do is
not do unusual calls which jude monitors, which would appear
from the docs to be execve.
You don't need to call execve to have all sorts of evil fun.
open and write (something most processes do quite legitimately)
will suffice. So will open and read.
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 problem really isn't the code that an exploit executes, the problem
is that the exploit can allow for "root" access by allowing the
code to spawn a new shell.
It doesn't need to spawn a new shell to allow root access. It
can just load the a properly-linked shell into memory (not
calling execve), then jump to main.
Or it can not use a shell at all. Shells aren't special in any way.
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?
A script kiddie is someone who downloaded some exploit code off
the 'net, and goes and tries it against random boxes. Or against
popular boxes. If his downloaded code does not work, he's stuck.
Might not even know C. Probably doesn't understand how the
exploit works. He'll give up or try another box.
A dedicated attacker, to me, is a person with a lot more
experience, a lot more time to use to attack you, and a reason
to attack that box specifically. He does read the source of
programs, looking for holes. He will manage to find the tricks
you've put into place, and, given enough time, get around them.
I confess that the danger to most people is the former. You have
to be protecting fairly important information to get the latter.
Or be otherwise important.