Concerning possible bugs in the 'inn' package

Russ Allbery rra at stanford.edu
Fri Sep 2 19:47:02 UTC 2005


Forrest J Cavalier <mibsoft at epix.net> writes:
> Russ Allbery wrote:

>> 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.

This problem only has security implications if one of the first three file
descriptors is closed, yes?  Isn't there a way to determine whether a file
descriptor is open or closed?  If so, we can just burn file descriptors in
the unusual case.

> 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.

Solving it in the operating system is certainly significantly more
attractive than modifying every user space program, but of course we can't
rely on all operating systems to be that wise.

> 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.

Er, I don't get this statement.  I can see modifying inews and rnews, but
I don't see how anyone can manipulate the file descriptor startup of innd
or nnrpd without already having all the requisite privileges to do
whatever damage they want themselves.

> 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.

I'm not worried about resource consumption so much as it's just a really
ugly fix.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the inn-bugs mailing list