RFC: Too many race conditions.

[mark@mark.mielke.cc]

On Sun, May 20, 2007 at 10:02:48PM +0200, Florian Weimer wrote:
> * Andrew Haley:
> > Hmm.  This depends, does it not, on the fact that a blocking call does
> > not return when a file descriptor is closed?  This sounds to me like a
> > bug in the kernel,
> I think the fundamental issue is that the object associated with the
> descriptor might change before the system call is even issued.

Yes.

> > Is this an exploitable security hole?  I suppose it is.
> Yes, that is my hunch as well.  Which means that it needs to be fixed
> if you ever want to support mobile code.

I suspect exploiting the condition would be difficult - even if you
could get the situation to occur, it still has to be in a place that
would allow something bad to happen. In the situation described,
it seems that you could trick the server into issuing an accept()
on the wrong file descriptor. Perhaps if the socket is trusted and in
administrator mode?

I am more concerned about wrong application behaviour, than about an
exploitable security hole. Having my server fail in a situation that
should be a controlled exception does not appeal to me.

As I read this issue, though, this should only happen in a scenario
where a file descriptor is used by one thread, closed by another, and
a third thread opens a new file descriptor at approximately the same
time. In most cases of mine, the close() is always the last operation
performed. It is only the blocking server socket accept() loop that
brings this race to the surface. It is yet another reason for me to
consider using a non-blocking server socket instead.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/