BugTraq
Multiple OS kernel insecure handling of stdio file descriptor Jan 18 2007 02:21PM
XFOCUS Security Team (security xfocus org) (3 replies)
Re: Multiple OS kernel insecure handling of stdio file descriptor Jan 19 2007 11:19PM
Shiva Persaud (shivapd austin ibm com) (1 replies)
Re: Multiple OS kernel insecure handling of stdio file descriptor Jan 20 2007 05:43PM
eugeny gladkih (john drweb com)
Re: Multiple OS kernel insecure handling of stdio file descriptor Jan 18 2007 09:04PM
Peter Jeremy (peter jeremy alcatel-lucent com au) (1 replies)
Re: Multiple OS kernel insecure handling of stdio file descriptor Jan 20 2007 06:35PM
Carson Gaspar (carson taltos org)
Peter Jeremy wrote:
> On 2007-Jan-18 22:21:52 +0800, XFOCUS Security Team <security (at) xfocus (dot) org [email concealed]> wrote:
>> The affected OSes allows local users to write to or read from restricted
>> files by closing the file descriptors 0 (standard input), 1 (standard
>> output), or 2 (standard error), which may then be reused by a called
>> setuid process that intended to perform I/O on normal files. the attack
>> which exploit this vulnerability possibly get root right.
>
> This vulnerability has been known for years. OpenBSD implemented a
> kernel check to block this attack in 1998. FreeBSD and NetBSD have
> similar kernel checks and I believe glibc also has checks to block
> this. It is disturbing that none of the commercial OS vendors appear
> to have bothered to protect against this.

Of course the _real_ problem is the badly written setuid app. Kernel
checks for "special" fds are just a condom to try and protect against
broken code. Not that such checks aren't a good idea (since so much code
is so very broken), but any app that is vulnerable to this attack needs
to be patched.

You'll note that the original advisory fails to specify any setuid apps
that are vulnerable to this attack, other than their broken POC. *yawn*

--
Carson

[ reply ]
Re: Multiple OS kernel insecure handling of stdio file descriptor Jan 18 2007 06:30PM
3APA3A (3APA3A SECURITY NNOV RU)


 

Privacy Statement
Copyright 2010, SecurityFocus