Re: TCPwrappers race condition

[wietse () WZV WIN TUE NL (Wietse Venema)]

Thamer Al-Herbish describes a race condition where a TCP client
resets a connection before the server has looked up the client
network address via getpeername().

This race condition is inherent to many UNIX kernel implementations,
and therefore it cannot be fixed with user-level code (tcpd, inetd,
or even with Bernstein's tcpserver/tcpcontrol software).

Although the time window can be made *smaller* by using results
from accept() instead of getpeername(), the time window can be
eliminated only by changing the kernel so that it does not destroy
the protocol control block when the connection is reset by the
peer.

Consider "connect from unknown" messages as an indicator that the
system is being portscanned.

        Wietse

Thamer Al-Herbish writes:
> I havent seen much discussion about this in the past on any forum. I thought
> I'd bring up the issue. Although I have seen alot of questions related to
> it, go unanswered.
>
> TCPwrappers do a getpeername() after bieng passed the socket descriptor from
> inetd. On some OSs this can cause a problem, atleast on SCO. It seems that
> if you connect real fast, and disconnect (just connect() then exit()). It
> winds up logging "unknown" as the hostname. This is because by the time
> tcpwrappers get to make that call the OS has already gotten a FIN and closed
> off the connection. I verfied this with a sniffer.
>
> Unfortunately this is a design issue, TCPwrappers "cant" be fixed to do this
> without modification to inetd. If the address from accept() was given to the
> tcpwrapper via an environment variable this would fix the problem and
> eliminate the race condition.
>
> Mind you tcpserver/tcpcontrol by Dan Bernstein already does the environment
> variable passing.
>
> --
> Thamer Al-Herbish
> shadows () whitefang com