Re: [NSE] rpc.lua fix for binding to reserved ports (tcp)

[David Fifield <david () bamsoftware com>]

On Thu, Sep 20, 2012 at 09:39:41AM -0500, Daniel Miller wrote:
> rpc-grind and possibly other scripts will take a long time timing out
> with every source port between 600 and 1024, since that portion of
> rpc.lua doesn't check the type of failure (timeout vs. port in use,
> specifically).

I didn't realize that rpc.lua was doing this, testing up to 400 local
ports for *every* call to Comm.Connect. I don't think it's a good idea.
It turns out to be an indirect cause of running out of sockets in
rpc-grind as described in
        http://seclists.org/nmap-dev/2012/q3/864
        http://seclists.org/nmap-dev/2012/q3/872

Old pos_scan didn't do this, right? Even if there is a good reason for
it (maybe some services require the other side to be bound to a
privileged port), what is the chance that after we've failed to bind to
the first 200 local ports, that any of the remaining 200 will work? Why
don't we just try, say, five ports at random, and give up after that?

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