bugtraq - Re: Need help. Proof of concept 100% security.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 18 Aug 2003 17:18:47 +0100
From: Anil Madhavapeddy <anil@...oil.org>
To: Alaric B Snell <alaric@...ric-snell.com>
Cc: Balwinder Singh <balwinder@....net>, bugtraq@...urityfocus.com
Subject: Re: Need help. Proof of concept 100% security.

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