Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: nmap: [REGRESSION 5.00-3 -> 6.00-0.3] -sP fails with "nexthost: failed to determine route to X.X.X.X"
From: Daniel Miller <bonsaiviking () gmail com>
Date: Wed, 31 Jul 2013 20:16:56 -0500

I tracked this down a while back, but I don't remember what happened to my
report. Essentially, you've run up against a limit in the Linux kernel that
can be tuned. The setting mentioned,
"/proc/sys/net/ipv4/neigh/default/gc_thresh3",
is the max number of arp cache entries. If
 your network has more than the default 1024 addresses, then this table can
fill up. It won't in most cases, even if you set it to a lower number,
since most networks are sparsely populated.

It's not a bug in Nmap, because I can produce the same issue with:

    sudo ifconfig eth0:0 10.10.0.0 netmask 255.255.0.0
    for i in {1..255}; do for j in {1..254}; do ping -c 1 10.10.$i.$j &
done; done


Dan


On Wed, Jul 31, 2013 at 3:33 PM, David Fifield <david () bamsoftware com>wrote:

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/

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault