Re: NSE Connection Problems on Windows?

[David Fifield <david () bamsoftware com>]

On Wed, Oct 17, 2012 at 10:09:15AM +0100, Rob Nicholls wrote:
> > -----Original Message-----
> > From: David Fifield [mailto:david () bamsoftware com]
> > Sent: 11 October 2012 18:09
> > To: Rob Nicholls
> > Cc: Nmap dev
> > Subject: Re: NSE Connection Problems on Windows?
> >
> > On Thu, Oct 11, 2012 at 03:59:18PM +0100, Rob Nicholls wrote:
> > > I've recently experienced some weird behaviour running NSE scripts
> > > using a version of Nmap I've built myself from SVN on Windows. It
> > > seems to affect scripts that access the same port (e.g. ntp, snmp),
> > > where one or more of them seem to execute properly and then the
> > > remaining ones seem to hang (presumably forever). When it happens,
> > > Nmap will just say something like:
> ...
>
> > Maybe you can bisect this and find a revision where it broke?
>
> The issue appears to start with r29631:
>
> 29479 - works
> 29567 - works
> 29625 - works
> 29627 - works
> 29628 - works
> 29631 - bad
> 29638 - bad
> 29648 - bad
> 29787 - bad
>
> It's not immediately obvious to me why it starts with that revision, but
> maybe it's another UDP port bug in the rpc-grind code? I should probably
> mention that the host I'm scanning doesn't respond to any requests on that
> range of UDP ports (100-200), so service/version scanning shouldn't identify
> any services, but perhaps it sets some default service names?
>
> When I disable service/version detection the scan completes fine. I've also
> just tried replacing the portrule in rpc-grind.nse to always return false
> and then the scan runs okay too.

I can reproduce this with the command line

nmap -sUCV -n -Pn --version-intensity 0 -p 100-200 -d --packet-trace -d2 --stats-every 10s <target>

When the hang happens, it's one or a few UDP-using scripts, and they are
all stuck in "connect". Nsock is never selecting the relevant socket
descriptors readable or writable. I don't know if it's because the
descriptors have somehow been removed from the fd_sets, if they are in
the fd_sets but for some reason Windows doesn't consider them
selectable, or for some other reason.

The connection attempts never time out because the events have a timeout
tv_sec of 0, which prevents this code in nsock_core.c from running:
        if (!nse->event_done && nse->timeout.tv_sec && !TIMEVAL_AFTER(nse->timeout, nsock_tod))
          handle_connect_result(nsp, nse, NSE_STATUS_TIMEOUT);
That is probably another bug.

Somehow the large number of connectionless packets sent by rpc-grind
have something to do with it, but I don't think it's the exact cause.
It's not just the sheer number of port either; if you leave ports 137
and 161 out of the specification (-p 100-136,138-160,162-200), then the
scan finishes.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/