Reported by multiple users on Windows 8.1 and Windows Server 2012 R2.
Seems to hang when the WinPCAP driver is accessed via OpenServiceA by
multiple processes at once. Users report that this change, which uses a
mutex to avoid concurrent access, fixes the hang.
for file in `grep "* including the terms and conditions of this license text as well. \*" * -r --files-with-match `; do sed "s/\* including the terms and conditions of this license text as well. \*/* including the terms and conditions of this license text as well. */g" -i $file; done
The previous code to ignore down interfaces didn't account for implicit
routes that come from interface addresses and netmasks. You can force
the use of a route using a down interface with -e.
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
