mailing list archives
Re: Need help. Proof of concept 100% security.
From: Anil Madhavapeddy <anil () recoil org>
Date: Mon, 18 Aug 2003 17:18:47 +0100
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:
... 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
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