> 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...
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:30:53 PDT