trusting user-supplied data (was Re: FreeBSD Security Advisory FreeBSD-SA-02:23.stdio)

[James Ralston <qralston+ml.bugtraq () andrew cmu edu>]

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