Re: nmap -sT localhost showing ephemeral ports?

[Daniel Miller <bonsaiviking () gmail com>]

On Fri, Feb 14, 2014 at 12:14 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
> On 02/14/2014 11:21 AM, Daniel Miller wrote:
> > I think the attached patch detects and fixes this. It seems to work on my
> > Linux system, and I think I haven't used any non-portable calls. I'd
> > appreciate testing.
>
> I realized I left a debug statement without a check for o.debugging and with
> an extra format argument. Corrected patch attached.
>
> Dan

List,

When checking to see how far back my patch would cleanly apply, I
found the interesting case of r30583:

------------------------------------------------------------------------
r30583 | david | 2013-02-05 04:55:29 +0000 (Tue, 05 Feb 2013) | 9 lines

Remove some old Linux compatibility code from connect scan.

This code was quite old (dating from r854 in 2000) and may not serve a
purpose anymore. Let's try removing it.

Apart from being obsolete, the code had a race condition where the
connection could be closed with a RST before getpeername was called,
leading to a fatal error message.

------------------------------------------------------------------------

The code in question did something similar to what I've done in this patch:

>   if (getsockname(sd, (struct sockaddr *) &sout, &soutlen) < 0) {
>     pfatal("error in getsockname for port %hu", (u16) pport);
>   }
>   s_in = (struct sockaddr_in *) &sout;
>   s_in6 = (struct sockaddr_in6 *) &sout;
>   if ((o.af() == AF_INET && htons(s_in->sin_port) == pport)
> #ifdef HAVE_IPV6
>         || (o.af() == AF_INET6 && htons(s_in6->sin6_port) == pport)
> #endif
>      ) {
>     /* Linux 2.2 bug can lead to bogus successful connect()ions
>        in this case -- we treat the port as bogus even though it
>        is POSSIBLE that this is a real connection */
>     newportstate = PORT_CLOSED;
>   } else {
>     newhoststate = HOST_UP;
>     newportstate = PORT_OPEN;
>   }

This may explain why this report only came up recently, if there was
code to handle the case prior to February 2013. I think my code is
safer with respect to the race condition because I simply mark the
probe as timed-out and allow it to be retried, counting on the low
probability of re-triggering the self-connection condition. Of course,
I am not certain that my implementation is entirely correct. It works
for me so far, but others more familiar with the API may discover that
I am introducing some other bug.

Dan
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/