[25235] in bugtraq
trusting user-supplied data (was Re: FreeBSD Security Advisory
daemon@ATHENA.MIT.EDU (James Ralston)
Wed Apr 24 12:36:54 2002
Date: Tue, 23 Apr 2002 20:18:29 -0400 (EDT)
From: James Ralston <qralston+ml.bugtraq@andrew.cmu.edu>
To: Bugtraq <bugtraq@securityfocus.com>
In-Reply-To: <20020422223025.94EAB7B4B@berkshire.research.att.com>
Message-ID: <Pine.LNX.4.44.0204231548220.12386-100000@pcmy.sei.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
