NStorm reported a failure of ARP ping scan on OpenVZ venet devices,
which don't have a MAC address and can't do ARP. We don't keep interface
flags such as NOARP at the target level, so check whether the interfaces
returned by libdnet are both INTF_TYPE_ETH and don't have
INTF_FLAG_NOARP set; otherwise call them "other" interfaces.
http://seclists.org/nmap-dev/2013/q1/349http://openvz.org/Virtual_network_device
Nping calls route_dst at least twice: once with a NULL device, and again
with the device learned from the first time. This interfered with the
code that automatically chooses a loopback interface for dests that are
the same as an interface address. For example, if you are 192.168.0.1,
and you are scanning 192.168.0.1, route_dst will tell you to use
interface "lo0" even though the interface of 192.168.0.1 may be "eth0".
route_dst was returning failure because the device name check was being
done before "eth0" got changed to "lo0".
This problem didn't show up on Linux because Linux uses
route_dst_netlink, which delegates the work to the kernel. But I could
reproduce on Linux by forcing the use of route_dst_generic.
This used to be used to hold the original argv before quashing with -q.
Now that -q is gone, it was just a copy of argv.
fakeargv was also causing Valgrind to complain about leaked memory. it
wasn't a real leak, but now it's out of the report anyway.
This is a refactoring of target parsing that stores different types of
target specifications as different classes. The eventual intention is to
allow easy iteration over each specification for the purpose of IPv6
multicast host discovery.
There was an embarrasing bug here added in r28874. In the second of
three calls to get_srcaddr, the interface was being indexed by an index
variable that, in this place, was actually an index into the routes
table. This would in general produce a nonsensical source address or
out-of-bounds access.
The symptom of this problem was the following error messages:
get_srcaddr: can't connect socket: The requested address is not valid in its context.
Failed to convert source address to presentation format!?! Error: Unknown error
The first showed that get_srcaddr failed, and the second was caused by
the bogus source address.
http://seclists.org/nmap-dev/2012/q3/859http://seclists.org/nmap-dev/2012/q4/59
When an interface doesn't have an address set, getInterfaceByName can
fail because it checks the address family. The fatal error message would
be something like
route_dst_netlink: can't find interface "tap0"
If we can't find an interface with a specific address family, fall back
with an AF_UNSPEC search.
http://seclists.org/nmap-dev/2012/q4/12
This commit fixes two different bugs:
(1) First in some situations Nmap will only see routes that are attached
to the device that handles the default route.
(2) On boxes without a default route, Nmap will not see any route.
These two bugs are caused by sysroutes_dnet_find_interfaces() logic
which will use only the geteway to match interface addresses.
To fix this, first check the current route and see if the gateway was set
otherwise use the destination address to match the address of an
interface.
Besides the confusingness of the nodns argument being negatively
phrased, it had the value 0 in every existing call. Split out the nodns
special case into a separate function resolve_numeric.
This also has the side effect of changing the number of parameters to
the resolve function, which will cause a compile error for any calls I
might have missed changing when I changed the return code meaning in the
previous commit.
Ncat has its own copy of resolve, which obeys the global o.nodns rather
than a parameter. I'm leaving that alone for now. But give it the same
resolve_internal function, and make resolve call it with different flags
depending on the value of o.nodns.
The only error we can have apart from a getaddrinfo error is a list of
zero addresses; return EAI_NONAME in that case.
This unfortunately inverts the truth value of the return code of
resolve; 0 now means success.
The second argument to RTA_NEXT was missing a dereference, so it was
changing the pointer rather than the integer pointed to. I got this
assertion failure with an IPv6 link-local address:
nmap: netutil.cc:3048: void add_rtattr_addr(nlmsghdr*, rtattr**, unsigned int*, unsigned char, const sockaddr_storage*): Assertion `((*len) >= (int)sizeof(struct rtattr) && (*rtattr)->rta_len >= sizeof(struct rtattr) && (*rtattr)->rta_len <= (*len))' failed.
This value gets clobbered after the netlink recvmsg. It was giving me a
bogus address family (234), which caused the call to getInterfaceByName
to fail:
Could not find interface wlan0 which was specified by -e
This seems to have been exposed by r29754. Specifying a source address
that is not on any actual route seems to result in a netlink query
result with 0 entries, and the changed value of rtm_family. (The fact
that there are no routes returned is not a problem, because we bail out
early when -e is given, now that getInterfaceByName works again.)
We previously restricted by destination address; do it for source
address as well. This can matter in some configurations.
http://seclists.org/nmap-dev/2012/q3/831
There still seems to be a problem with the wrong route being chosen with
--send-ip, but this patch is reported to work with --send-eth.
According to rtnetlink(7), such routes are "an unreachable destination."
I get such a route when I ifdown my he-ipv6 interface:
$ /sbin/route -n -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::/0 :: !n -1 1 26122 lo
The problem with not ignoring such routes is that Nmap will think that
the interface to use is lo, and consequently that all the targets are
localhost addresses. Ping scan will succeed with a localhost-response,
but trying to send any packets will fail with "destination unreachable."
Maybe we should do the same thing for these additional values of
rtm_type?
RTN_BLACKHOLE a packet dropping route
RTN_PROHIBIT a packet rejection route
Since r24413, we have tried "connecting" a UDP socket and using
getsockname in order to infer our source address. This replaced previous
behavior of always using the interface address. However, this appears to
fail when scnning certain *.0 addresses on Windows XP. So fall back to
the old behavior.
http://seclists.org/nmap-dev/2012/q2/464
Sendto has logic to automatically sleep and retry a send if it fails.
Fyodor tells me that it was once necessary because of some transient
buffer shortage, though we can't remember the exact error it was in
response to.
The retry looks as though it has been slowly growing a list of
exceptional error codes for which sleeping is not done:
EPERM EACCES EMSGSIZE EADDRNOTAVAIL EINVAL
The latest was EMSGSIZE in r19378.
I changed this to only sleep on specific errors. Not knowing what the
original error was, I have guessed
ENOBUFS ENOMEM
Solaris 11 uses BPF packet capture rather than DLPI, which requires
different handling in many cases. The new preprocessor symbol tells when
this is the case; it is additional granularity on top of SOLARIS.
I was surprised when I found that Solaris 11 scanning works now. I
thought that it would require a change in the defines around
pcap_selectable_fd_valid, because it's valid for Solaris 10 and earlier
but not for Solaris 11. Why it started working was the
pcap_selectable_fd_one_to_one test added in r28319. As a side effect of
that function overrides pcap_selectable_fd_valid for all Solaris
releases, it makes changes in pcap_selectable_fd_valid unnecessary.
However it is indirect in the way it does it, so I'm adding a comment
explaining the situation and a hope that there is an easy change to make
pcap_selectable_fd_valid correct on its own.
This is designed to solve the following problem: On Solaris 10 (maybe other
platforms), doing a select on a pcap fd works, in that it returns true when
there are frames available to be read. However, after finding the fd selectable
and calling pcap_dispatch (or pcap_next, etc.), libpcap may read more than one
frame and buffer them internally. This means that later calls to select will
return false. So there may be a frame to be read, but you can't know without
calling pcap_dispatch to check, and that blocks indefinitely (on Solaris) if
you're wrong.
The way this works is that we do a non-blocking read on the pcap fd to see if
there is anything available. If not, we do a select with a timeout as usual.
(The select is to enforce the timeout and prevent spinning CPU by repeatedly
trying non-blocking reads.)
I don't know if this phenomenon affects other platforms than Solaris 10
(more specifically, platforms using DLPI for libpcap). This same thing may be
safe or necessary on other platforms. But I have limited it to Solaris for now.
Solaris 11 uses BPF, not DLPI, for libpcap, but we can unconditionally follow
this code path on Solaris because BPF pcap fds can't be selected on.
The difference is that ip_get_data_any doesn't require there to be an
upper-layer header at the end of an IPv6 chain. This avoids the message
"BOGUS! Can't parse supposed IP packet" during -sO -6 scan. The -sO
sends non–upper-layer headers, some even with empty payloads, and so
causes this situation often.
This often comes up these days with IPv6 routes that don't seem to
affect scanning. I don't think we have problems with routes being
removed when they shouldn't be anymore.
This makes Nmap assume that pcap sockets are selectable on Solaris again. I had
originally tested this on Solaris x86, and couldn't get a scan to complete witho
ut this change. But it was reported that it fails on Solaris SPARC (scans take a
long time, indicating that pcap calls are blocking longer than their timeout).
I just tested it again on Solaris x86, and now I can't get a scan to complete wi
th r26741. So reverting.
Some function declared parameters like this:
int f(const char * const s)
Where appropriate, I changed to
int f(const char *s)
The second const is a qualifier on the pointer itself; i.e., the value
of s may not be changed (may not be made to point to anything else)
within the function. This is probably not what was intended. The first
const is what prevents modifying things referenced through s.
