Concerning possible bugs in the 'inn' package

David Wagner daw at cs.berkeley.edu
Fri Sep 2 21:53:10 UTC 2005


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

Something like
  close(0); close(1); close(2);
  fd0 = open("/dev/null", O_RDONLY);
  fd1 = open("/dev/null", O_RDONLY);
  fd2 = open("/dev/null", O_WRONLY);
  (if any of the closes or opens failed, die)
ought to have the same effect.  In the normal case where the program is
started with all fds 0,1,2 all opened, then this burns 0 fds.  In the case
where you are under attack, who cares how many fds you burn?

Am I missing something?

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

Sounds right to me.  The file descriptor attacks are only a threat to
setuid or setgid programs (or programs called by setuid/setgid programs,
etc.).  For programs that are not installed setuid/setgid and where the
attacker cannot control the fds under which the program is executed,
file descriptor attacks are not a threat.



More information about the inn-bugs mailing list