Re: nmap: [REGRESSION 5.00-3 -> 6.00-0.3] -sP fails with "nexthost: failed to determine route to X.X.X.X"

[David Fifield <david () bamsoftware com>]

On Fri, Jul 05, 2013 at 09:50:18AM +0300, Timo Juhani Lindfors wrote:
> this was originally reported to
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714925 but here's a
> copy for upstream now that I know that it also occurs with upstream
> tarballs.
>
> Steps to reproduce:
> 1) configure eth0 to use 10.7.0.0/16 subnet
> 2) Run "sudo nmap -n -T normal -sP 10.7.24-34.1-254"
>
> Expected results:
> 2) nmap pings each host in the network
>
> Actual results:
> 2) nmap fails after it has processed 1024 hosts:
>
> Starting Nmap 6.00 ( http://nmap.org ) at 2013-07-04 14:35 EEST
> nexthost: failed to determine route to 10.7.28.5
> QUITTING!

Thanks for this excellent bug report.

I haven't been able to reproduce it yet, but I haven't been on a
(simulated) network with more than 1024 live hosts.

> 8) strace shows that nmap-5.52.IPv6.Beta1 uses PF_PACKET/SOCK_RAW and
>    formats the ARP request on its own. nmap-5.52.IPv6.Beta2 on the other
>    hand seems to use PF_NETLINK/SOCK_RAW and asks the kernel to do the
>    ARP queries using NETLINK_ROUTE messages. Apparently this causes the
>    kernel to cache all these queries?

It's a little different--in both cases Nmap constructs and sends the ARP
packets on its own. IPv6.Beta2 uses PF_NETLINK sockets only for reading
the routing table--see the route_dst_netlink function. I suppose it's
possible that reading the routing table in this way causes ARP requests
to be sent implicitly, but I wasn't able to cause it and didn't find it
so documented anywhere.

In any case, I suspect that you are right that the change to Netlink is
the proximate cause of the the problem you encountered. A good quick
test is to edit libnetutil/netutil.cc to disable route_dst_netlink and
enable route_dst_generic, and see if the problem persists.

Another thing to try: The --route-dst option makes Nmap make a routing
decision, without sending pings or any other traffic. Try something like
        sudo nmap --route-dst 10.7.24.1
and see if it increases the number of ARP entries in the cache. If so,
we will have the problem localized closely.

> 9) Even an unprivileged user can do this (with -sT -p 100), is this also
>    a DoS?

It might be. You don't need special privileges for the Netlink
operations we're using.

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