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.
as for IPv4. This makes the output more uniform and gives NSE access to
host.targetname for IPv6 hosts.
This is what IPv4 output looks like:
$ nmap -sL www.kame.net
Nmap scan report for www.kame.net (203.178.141.194)
rDNS record for 203.178.141.194: orange.kame.net
Nmap done: 1 IP address (0 hosts up) scanned in 0.16 seconds
$ nmap -sL www.debian.org
Nmap scan report for www.debian.org (128.31.0.51)
Other addresses for www.debian.org (not scanned): 206.12.19.7
rDNS record for 128.31.0.51: senfl.debian.org
Nmap done: 1 IP address (0 hosts up) scanned in 0.17 seconds
Here is the output before this change. Notice that the target name is
missing and there is no separate "rDNS" line.
$ nmap -6 -sL www.kame.net
Nmap scan report for 2001:200:dff:fff1:216:3eff:feb1:44d7
Nmap done: 1 IP address (0 hosts up) scanned in 0.04 seconds
$ nmap -6 -sL www.debian.org
Nmap scan report for bellini.debian.org (2607:f8f0:610:4000:211:25ff:fec4:5b28)
Nmap done: 1 IP address (0 hosts up) scanned in 0.11 seconds
Here is the output after this change:
$ ./nmap -6 -sL www.kame.net
Nmap scan report for www.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7)
Nmap done: 1 IP address (0 hosts up) scanned in 1.04 seconds
$ ./nmap -6 -sL www.debian.org
Nmap scan report for www.debian.org (2607:f8f0:610:4000:211:25ff:fec4:5b28)
rDNS record for 2607:f8f0:610:4000:211:25ff:fec4:5b28: bellini.debian.org
Nmap done: 1 IP address (0 hosts up) scanned in 0.07 seconds
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.
report. It looks like this.
$ ./nmap google.com -sn
Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-05-10 23:57 MDT
Nmap scan report for google.com (66.102.7.99)
Host is up (0.073s latency).
Other addresses for google.com (not scanned): 66.102.7.104
rDNS record for 66.102.7.99: lax04s01-in-f99.1e100.net
This replaces the line
Hostname google.com resolves to 2 IPs. Only scanned 66.102.7.99
group. Not doing this was the cause of off-by-one errors that led to
assertion failures and, potentially, excluded hosts being scanned. Here
is the comment I added:
/* The decision to skip a range was based on the address that came immediately
before what our current array contains now. For example, if we have just
handed out 0.0.0.0 from the the range 0-5.0.0.0, and we're asked to skip
the first octet, we want to advance to 1.0.0.0. But 1.0.0.0 is what is in
the current array right now, because TargetGroup::get_next_host advances
the array after returning an address. If we didn't step back we would
erroneously skip ahead to 2.0.0.0. */
"base address" from which a group of addresses were derived, for example
in "scanme.nmap.org/24", "scanme.nmap.org" would be the base address.
Use these methods to set the target name of that one host even when
addresses come from a netmask.
strchr() per David's suggestion. strtok uses static (global) state to
track the string it is parsing. In this case, load_exclude was also
using strtok and calling parse_expr which was wiping out the previous
strtok state. This introduce two bugs, first, only the first exclude
on a line would be loaded from the exclude file, and second, there was
an invalid access into free()'d memory in load_exclude (found with
Valgrind). The use of strtok should be highly discouraged because
these types of bugs are so easy to introduce.
of "*.*.*.*" from working. Support for the CIDR /0 is now also
available. [Kris]
A sendto() or connect() to IPv4 addresses with a first octet of 0
(excluding 0.0.0.0 on some OS's) returns EINVAL. These addresses
are reserved for "self-identification" and should never go over the
wire (and at least on Linux a connect() to 0.0.0.0 gets redirected
to 127.0.0.1). I'm talking with Fyodor on whether or not to skip
*all* of these addresses.
On Windows, this ID has to be a numeric index. On Linux and some
other OS's, this ID can instead be an interface name. Some examples
of this syntax:
fe80::20f:b0ff:fec6:15af%2
fe80::20f:b0ff:fec6:15af%eth0
This was a lot simpler than the method I previously implemented and posted
to nmap-dev. Now I just extract the zone ID from the already available
getaddrinfo() data rather than parsing it out myself.
line, since this can differ from the reverse DNS results. It can be
particularly important when doing HTTP tests against virtual hosts.
The data can be accessed from target->HostName() from Nmap proper
and host.targetname from NSE scripts. The NSE HTTP library now uses
this for the Host header. Thanks to Sven Klemm for adding this
useful feature.
