Concerning possible bugs in the 'inn' package

Forrest J. Cavalier III forrest at mibsoftware.com
Fri Sep 2 12:26:28 UTC 2005


Russ Allbery wrote:

> Ben Schwarz <bschwarz at EECS.berkeley.EDU> writes:
> 
> 
>>The specific type of bug which we have found stems from the standard
>>file descriptors (FDs) on a Unix system. Typically, when a process is
>>started, FD 0, 1 and 2 are set to standard in, standard out, and
>>standard error respectively. Subsequent uses of input and output
>>functions--such as printf--will read or write from one of these three
>>descriptors. Customarily, a program starts with its standard file
>>descriptors opened to terminal devices. However, since the kernel does
>>not enforce this convention, an attacker can force a standard file
>>descriptor of a victim program to be opened to a sensitive file, so that
>>he may discover confidential information from the sensitive file or
>>modify the sensitive file.
> 
> 
> It makes no sense to me that this would have security implications.  Could
> you explain a little bit more?  The attacker has to have access to open
> the file in the first place in order to redirect output from an
> application to that file, and if they have access to open the file in the
> first place, they can just read the file or write to the file themselves.
> 

The problem is that fd0,1,2 (stdin/stdout/stderr) have been treated as
known entities by all sorts of library and code, and it is impossible
to know all those platform-specific ways that something could be induced
to write to stdout/stderr.

So an exploit works like this: attacker finds a way to influence a running
program to use fd 0,1,2, then induces some state or condition that causes
the program to write or use input from stdin/stdout/stderr.

With the right combinations, you can do some pretty interesting things.

I don't think INN is a high risk with this one, because it uses printf so
sparingly, if at all, but software is complex, libraries on a lot of platforms
are unique.

Plus programmers are really bad about understanding all code execution paths.
We have a mental block blinding us from seeing all the weird ways that an
attacker can get our code to dance differently than we intended when we wrote
it.




More information about the inn-bugs mailing list