There was one case where we previously didn't fatal, in nse_dnet.cc.
Move the fatal calls out of nmap_raw_socket and into the calling scope,
with the exception of the one in nse_dnet.cc.
The problem was reported by Rob Nicholls.
http://seclists.org/nmap-dev/2012/q4/186
I believe the purpose of these asserts was to quiet a compiler warning
in r24309, but the rest of that revision (marking fatal as a
non-returning function) should do the job.
This is what setTargetNextHopMAC already did, but the code change was
not copied here. This provided a way for NSE scripts to cause an
assertion failure:
local math = require "math"
local packet = require "packet"
function portrule(host, port)
return port.protocol == "udp"
end
function action(host, port)
local ip_raw = bin.pack("H", "60000000000d11ff")
.. host.bin_ip_src .. host.bin_ip
.. bin.pack(">S", math.random(32768, 65535)) .. bin.pack(">S",
port.number)
.. bin.pack("H", "000d8082") .. "hello"
local p = packet.Packet:new(ip_raw, #ip_raw)
p:udp_count_checksum()
local s = nmap.new_dnet()
s:ip_open()
s:ip_send(p.buf)
end
This would fail with the message "doArp can only handle IPv4 addresses"
when ip_send called getNextHopMAC. (Only with --send-eth.)
You could use "-e en0" to automatically add scope ids to your IPv6
addresses, so you didn't need the write "fe80::1234%en0". But this only
happened for the route_dst calculation, and could lead to later failures
in sendmsg when the address didn't have a scope id.
The comment in struct_ip.h explains the reasoning for this. The AIX C library
uses #defines that change the names of members of struct ip, and conflict with
some existing code. (Notably struct ip_hdr in libdnet and IPv4Header::h in
libnetutil.) We can still use the AIX files if we include <netinet/ip.h> after
this other code has been preprocessed. That's hard to enforce when
<netinet/ip.h> is included from another header file; this new file allows
including it always late, and only where needed.
Heretofore we have always extracted teh destination address directly
from the packet contents. But the raw packet bytes do not contain enough
information in one case: IPv6 link-local addresses. For those we really
need the scope ID, and for that we must pass this information all the
way down.
Before this, I got "no route to host" on OS link-local addresses. I
think that it was working on Linux only on accident, by the OS picking a
default interface or something.
This restores the previous behavior of these functions, which was broken
in r24127, which itself was fixing another bug.
r24127 solved the problem of --data-length appending zeroes, not random
data, to ICMP and IGMP packets. But in doing so, it added a check that
the data argument is not NULL. OS detection uses a data argument of
NULL, expecting these functions to fill in zeroes in this case. The
result of this was that the IE probes were being sent with empty
payloads instead of 120 and 150 bytes.
We should have the multiprotocol version be the main version, with
IPv4-only code being a noted exception. Also these functions are almost
the same so one can call the other.
returning floating-point seconds. Everywhere o.TimeSinceStartMS was
called, the return value was being divided by 1000.0, which had the same
effect but would overflow when the difference exceeded about 25 days
(2^31 milliseconds). This patch is by Daniel Miller.
unspecified and causes a segmentation fault on Android Bionic libc.
Vlatko fixed the bug in his Android binaries and it was first reported
by @alexismm2.
resolve except that it returns all resolved addresses. Use this new
function to resolve IPv4 addresses instead of gethostbyname in
TargetGroup.cc. The gethostbyname code assumed that only IPv4 addresses
would be returned. If the resolver returned IPv6 addresses, TargetGroup
would blindly copy the first four bytes of the IPv6 address into the
IPv4 struct. This was first reported by Mats Erik Andersson at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584301; he also
suggested the fix.
