[31263] in bugtraq
Re: Need help. Proof of concept 100% security.
daemon@ATHENA.MIT.EDU (Anil Madhavapeddy)
Mon Aug 18 17:04:28 2003
Date: Mon, 18 Aug 2003 17:18:47 +0100
From: Anil Madhavapeddy <anil@recoil.org>
To: Alaric B Snell <alaric@alaric-snell.com>
Cc: Balwinder Singh <balwinder@gmx.net>, bugtraq@securityfocus.com
Message-ID: <20030818161847.GA20303@quick.recoil.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F3D5852.2090008@alaric-snell.com>
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
