On Mon, 22 Apr 2002, Steven M. Bellovin wrote: > It's amazing that this has taken so long to resurface. This is an > ancient bug -- see, for example, Henry Spencer's suid man page from > 1987 This is a specific instance of a more general issue: namely, that the file descriptor table is inherited from the caller, and thus should be treated with the same amount of distrust as other user-supplied data. Just as any security-conscious program should assume that the environment variables it inherits may have been manipulated in an attempt to exploit it, any security-conscious program should assume that the file descriptor table it inherits may have been manipulated in an attempt to exploit it. Leaving one of stdin/stdout/stderr closed is one exploit attempt. Another exploit is to open all but a few file descriptors, which can cause results from the program silently failing to syslog() anything, to the program crashing entirely. Stevens[1] recommended 10 years ago that any daemon program should close all unneeded file descriptors. That principle applies to any security-conscious program as well--closing a few thousand file descriptors once at startup is inexpensive, as is testing at startup to make sure that stdin/stdout/stderr are all open, and opening them to a data sink (e.g. /dev/null on unix systems) if they are not. (Unless daemons need stdin/stdout/stderr, they should close them and reopen them to /dev/null.) [1]: Advanced Programming in the UNIX Environment, W. Richard Stevens, Addison-Wesley, 1992. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA
This archive was generated by hypermail 2b30 : Wed Apr 24 2002 - 09:39:21 PDT