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

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 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.

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.

Reply to: