> Fast Emergency AVET Response
> SECURITY ADVISORY
> January 2000
> FEAR ID: 1
> *BSD procfs vulnerability
[...]
>
> The solution (by deraadt) is to add a certain check in execve syscall. If
> a process X tries to exec a setuid binary, we make sure it holds no open
> descriptors pointing into procfs filesystem.
Actually, my patch only checks descriptors 0, 1, and 2. Todd and I
thought long and hard, and could not think of a setuid process which
would expect a provided descriptor higher than 2 to be kosher for
writing to. Such processes are very careful with those descriptors.
But descriptors 0, 1, and 2 are special cased by libc. libc assumes
it can splat to them, and setuid programs use libc.
While mostly dealing with procfs, this advisory also has a lot in
common with the un-allocated fd advisory that we made available in
June of 1998. In that case, leaving file descriptors 0, 1, or 2
unallocated at execution time would cause a setuid process to open
it's next descriptor into one of those slots. For sake of argument,
let's pick 2 (0 and 1 are open on files, 2 is not). If the setuid
process opens a new file for write, which becomes descriptor 2, and
then a bad condition causes it to write to stderr, it will have
written over the file it opened.
See http://www.openbsd.org/errata23.html#fdalloc
We actually never found anything that could be exploited by this
problem, but we didn't look for a specific attacks to this generic
problem. Instead, we fixed the kernel because we feel that setuid
programmers already have far too much to worry about, without having
to worry about descriptors 0, 1, and 2 being allocated.
The reason I mention all this, is that the handling for this procfs
issue is now handled by the same chunk of code that solves the fdalloc
issue...
