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

[ reply ]