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

From: James Ralston (qralston+ml.bugtraq@andrew.cmu.edu)
Date: 04/24/02 

Date: Tue, 23 Apr 2002 20:18:29 -0400 (EDT)
From: James Ralston <qralston+ml.bugtraq@andrew.cmu.edu>
To: Bugtraq <bugtraq@securityfocus.com>

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

Relevant Pages

  • Re: Transfering file descriptors between processes...
    ... >> case) and you want process B to have the file descriptor instead. ... >> any way of transfering the file descriptor from one process into ... > get a copy of Stevens' APUE is well taken. ... they answer questions _while_ plugging their books. ...
    (comp.unix.programmer)
  • passing file descriptor between processes
    ... I'm trying to pass file descriptor between 2 processes. ... Stevens. ... process B. I've also tried to open ttyS0 from process A, ... same code, I tried to open a custom device from process A, pass the ...
    (comp.os.linux.development.system)
Quantcast