Kenneth Frazier reported that sometimes Nmap would use name servers from
inactive interfaces. Let's try checking the interface GUIDs against
those known by libpcap.
http://seclists.org/nmap-dev/2013/q1/292
I don't find anywhere in the history where this value has ever varied.
This is an old post from Doug where he mentions possibly different
values, but they appear to have been unused.
http://seclists.org/nmap-dev/2006/q1/147
Reworked the logging infrastructure to make it more flexible
and consistent.
Updated nmap, nping and ncat accordingly. Nsock log level can
now be adjusted at runtime by pressing d/D in nmap.
The exceptions are the calls in ncat/ncat_connect.c and
nping/EchoServer.cc. Ncat doesn't have an option for the interface, and
I think Nping's -e option is only meant to apply to probes, not to the
echo server listener.
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.
When a DNS name was only "."; i.e., the first byte in its encoded
representation was 0, encoded_name_to_normal wouldn't null-terminate the
string. This caused multiple warnings
Illegal character(s) in hostname -- replacing with '*'
as later code read from uninitialized memory. Now we null-terminate
whenever the function returns success, and treat "." as a special case
for which we retain the trailing dot.
This bug was found by Gisle Vanem, who wrote a patch to fix it. I added
some more error checking to the patch.
ncat_proxy.c: In function `ncat_http_server':
ncat_proxy.c:163: warning: dereferencing type-punned pointer will break strict-aliasing rules
nmap_dns.cc: In function `void parse_resolvdotconf()':
nmap_dns.cc:951: warning: unsigned int format, different type arg (arg 4)
traceroute.cc: In member function `void TracerouteState::read_replies(long int)':
traceroute.cc:1031: warning: 'header_len' might be used uninitialized in this function
acommonate IPv6 addresses) and make the sscanf format size match the
buffer size (to avoid smashing the stack). The format string is
constructed dynamically to the size of the buffer with Snprintf. Gunnar
Lindberg reported this problem; discussion starts at
http://seclists.org/nmap-dev/2010/q1/250.
servers. Pass that to nsock_connect_udp instead of using
sizeof(sockaddr_storage). Mac OS X return EINVAL if the length is not what's
expected for the address family.
can be used in /etc/resolv.conf or with the --dns-servers option. The
parallel reverse DNS resolver still only support IPv4 addresses, but
it can look them up over IPv6. [Ankur Nandwani]
and --script-trace. It was set at 5, now it's 2. That's enough to see
all the Nsock events and the contents of reads and writes. At 3 you
start to get messages like
PCAP do_actual_pcap_read READ (IOD #%li) (EID #%li) size=%i
The message "wait_for_events" isn't printed until level 4. Getting rid
of that is the main reason for this change.
functions. Previously system DNS resolution was encapulated inside the parallel
DNS function, inside a big if block. Now the if is on the outside and decides
which of the two functions to call.
o Nsock now supports binding to a local address and setting IPv4 options
with nsi_set_localaddr() and nsi_set_ipoptions(), respectively. [Kris]
o Nmap's Nsock-utilizing subsystems (DNS, NSE, version detection) have been
updated to support the -S and --ip-options flags. [Kris]
might negitivly effect how efficiently nmap stores cache values in a hash
table. Now ntohl is called to correctly reorder the values on little endian
platforms before the hash calculation is preformed.
This changes the DNS engine to use addto_etchosts to add entries from
/etc/hosts into the DNS cache, rather than just inserting them using
push_front.
The reason for this is that there is a static unsigned variable in
addto_etchosts that keeps track of how many entries there are in the
cache. Using push_front bypassed this variable, allowing the entries in
/etc/hosts to sneak in under the radar. Thus is was possible for the
cache to contain, say, 266 entries when it thought it only had 256.
When the cache size is greater than or equal to 256, addto_etchosts runs
a deletion pass aiming to reduce the number of entries to 126. But the
peculiar loop logic of that function means that more than 256 entries
can be deleted. (How many more depends in part on how many entries there
are in /etc/hosts. There must be at least one for the hang to occur.)
When this happens, the signed counter underflows and becomes large
positive, ~65000. The code empties the cache trying to get the counter
under 127, but it can never happen.
To reproduce the hang, make an /etc/hosts file like this:
1.0.0.1 host-1-1
1.0.0.2 host-1-2
1.0.0.3 host-1-3
1.0.0.4 host-1-4
1.0.0.5 host-1-5
1.0.0.6 host-1-6
1.0.0.7 host-1-7
1.0.0.8 host-1-8
1.0.0.9 host-1-9
1.0.0.10 host-1-10
2.0.0.1 host-2
3.0.0.1 host-3
...
254.0.0.1 host-254
255.0.0.1 host-255
The hang can occur with even one entry in /etc/hosts, but saturating the
cache like this makes the hang less dependent on network conditions.
Then list-scan a netblock that is greater in size than 256 and is dense
in DNS entries (at least 256 entries per 4096 IP addresses). For
example,
nmap -sL scanme.nmap.org/22
works for me currently.
