Windows doesn't support selectable pcap fds, so instead of fiddling with
adapter read timeouts via PacketSetReadTimeout, we get an event handle
with pcap_get_event and WaitForSIngleObject. This means we don't need to
extract the adapter from the pcap_t, which is not part of the libpcap
API and was causing crashes switching between the libpcap versions used
by WinPcap and Npcap.
Two issues here: First, IP protocol scan can send packets with protocol
58 (ICMPv6) even over IPv4. This led to a bad interaction where the
packet was created (in build_protoscan_packet) without a data payload,
but setIP tried to set the packet's Identifier field (present in both
ICMPv6 and ICMP Echo Request packets), leading to a heap buffer
overflow. Instead, we now only try to set this identifier when the IP
version matches the ICMP version, indicating that we set the data
payload.
The other issue was a out-of-bounds read while packet tracing when an
ICMPv6 packet without a payload was sent or received, due to trying to
read the type and code. Now we check that the data length is sufficient
to contain an ICMPv6 header before attempting to read one.
Credit LLVM/Clang's AddressSanitizer with catching these bugs.
The formats has been tested and verified on Mac OS X 10.8.5,
Mac OS X 10.11.5 and Ubuntu 14.04 LTS, all on x86_64 machines
and OSs. It mainly silences warnings. There were no warnings on
Ubuntu but a few on Mac OS, so the fix is intended to silence
warnings on Mac OS whithout triggering new warnings on other OSs.
Example of warnings previously encountered:
netutil.cc:2828:74: warning: format specifies type 'unsigned short'
but the argument has type 'int' [-Wformat]
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
