Concerning possible bugs in the 'inn' package

Forrest J. Cavalier III mibsoft at epix.net
Fri Sep 2 19:37:23 UTC 2005


Russ Allbery wrote:

> Forrest J Cavalier <forrest at mibsoftware.com> writes:
> 
> 
>>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.
> 
> 
> Oh, okay, I think I get it.  The problem is if fds 0, 1, or 2 are closed
> going into the program, so that other files it opens end up pointing to
> those file descriptors.  The most likely results would be to get random
> crap written or read from the wrong files.

It has been exploited in other programs to gain root, create new users,
and other mischief.

> 
> Hm.  There's got to be some cleaner way of detecting and correcting for
> that than just burning three file descriptors at the beginning of the
> program.

Nope, there isn't because there is no way to audit all the stupid stuff
people coded into various libraries on all platforms.  I think there
was even an sbrk() implementation that complained to stderr on one of them.

I believe some security adjustments for Linux and others automatically
open /dev/null if the fds are not already used during an SUID, SGID exec,
So other people have thought about this and that is the solution they
came up with.

The same fix for INN makes sense becuase a server process like INN in fact
runs code on behalf of remote users, so it should get the same security
precautions as an SUID exec.

As for burning three fds, if some user really needs 256 or 1024 file descriptors on
those platforms something that have the stupid stdio limit, they have a big enough
installation that they can reach into the code and disable the code which
ensures they are open.

Don't make the change hastily.  I'm sure after you think about it for
a bit, it will seem like the right choice.



More information about the inn-bugs mailing list