problem was that the timer was including the time taken by the server to
do reverse-DNS resolution and an ident lookup, before it handled the
magic "AB" sleep command. So if a server took 10 seconds to time out the
ident lookup, the time recorded would be 10 seconds greater than it
should have been. If the timeout was long enough, as server would be
reported as vulnerable even if not. To compensate for this, the delay
was set high, but false positives were still possible and this slowed
down the script.
First, remove the mutex that allowed only one instance of the script to
run at a time. The mutex was meant to provide more accurate timing, but
it wasn't really needed because scritp parallelism wasn't the cause of
inaccuracy.
Next, make sure the server is done sending its initialization messages
(and hence is done with its timeouts) before sending the magic "AB"
sleep command and starting the timer. This is done by sending an
innocuous TIME command immediately upon connection. This is partly
because comm.tryssl has to send something, and partly because we can
detect when the server has processed the TIME command by looking for a
message like ":hostname 451 TIME :You have not registered". Once this is
done, we start the timer and send the "AB" command. If we haven't gotten
a response to TIME in 60 seconds, go ahead and send the "AB" command
anyway.
Finally, reduce the delay to 8 seconds from 25. The delay only has to be
long enough to overcome any network delay, now that confounding timeouts
have been eliminated. In a test of around 600 hosts, the only times I
recorded were 0, 1, 8, and 9 seconds, so this looks like a good enough
safety margin.
o The Windows executable installer now uses LZMA compression instead
of zlib, making it about 15% smaller. See
http://seclists.org/nmap-dev/2010/q2/1011 for test results. [David]
targets.cc, and return false if it is so. This indicates that we are not
doing a raw scan. target->deviceName != NULL is necessary before
checking target->directlyConnected(), otherwise you get this assertion
failure when doing any non-root scan (such as -sT or -sL) as root with
two or more targets:
nmap: Target.cc:369: bool Target::directlyConnected() const: Assertion `directly_connected == 0 || directly_connected == 1' failed.
Aborted
This is how the logic originally worked, and I accidentally broke it in
r17892.
o Fixed name resolution in environments where gethostbyname can return
IPv6 (or other non-IPv4 addresses). In such an environment, Nmap
would wrongly use the first four bytes of the IPv6 address as an
IPv4 address. You could force this, at least on Debian, by adding
the line "options inet6" to /etc/resolv.conf or by running with
RES_OPTIONS=inet6 in the environment. This was reported by Mats Erik
Andersson, who also suggested the fix. [David]
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.
