Bugtraq: Re: Need help. Proof of concept 100% security.

[Anil Madhavapeddy <anil () recoil org>]

On Fri, Aug 15, 2003 at 11:01:54PM +0100, Alaric B Snell wrote:
> If the target program *ever* performs, say, the syscalls required to 
> start up a shell (fork, some socket calls to set up a listener, accept, 
> then dups of fds then exec, say?) - even with other syscalls inbetween - 
> then the shell code might well perform the syscalls in order, using 
> dummy arguments for syscalls it doesn't want (open /dev/zero and read 
> blocks of 0 bytes from it and so on).
Wagner and Soto published a paper about these 'mimicry' attacks:
http://www.cs.berkeley.edu/~daw/papers/mimicry.pdf

... with regards to intrusion detection systems; same applies for host
based security.  It's a problem that any behavioural models based purely
on syscalls have a tough time getting around.  That, and how to reduce
the size of the FSM generated if you trace through all possible
permutations of the control flow statically.

> But still - it sounds promising; it reminds me of an idea I was 
> considering (but Theo de Raadt hated!) of allowing processes to drop 
> certain syscalls (or certain modes of operation of syscalls - many are 
> multi-function), shedding priveleges in the same manner as setuid-ing 
> down to nobody or chrooting. So Apache could, after binding to its 
> ports, drop the ability to bind to ports. After opening its log files, 
> it could drop the ability to open files for writing. Each child process 
> would abandon fork rights, and exec rights as soon as it sees it's not a 
> CGI.
It just adds another layer of complexity to an already over-complex
kernel/userland interface.  If you're going to change the source like this,
I prefer privilege separation instead, which works without kernel changes.

-- 
Anil Madhavapeddy                                   http://anil.recoil.org
University of Cambridge                            http://www.cl.cam.ac.uk