o Fixed the assignment of interface aliases to directly connected
routes on Linux, which was broken in 5.30BETA1 (it always assigned
the base interface instead of the alias). This was visible in the
host.interface variable passed to NSE scripts. The bug was reported
Victor Rudnev. [David]
in getsysroutes_proc. This was already being done for nonâdirectly
connected routes, those with a gateway. Victor Rudnev reported this bug.
The /proc/net/route file doesn't contain alias qualifications so we must
match them up after the fact with the interface table. When the gateway
address isn't set, use the route destination for matching instead.
For example, with these interfaces and routing table,
eth0 Link encap:Ethernet HWaddr 00:50:BF:16:11:61
inet addr:192.168.1.21 Bcast:192.168.1.255 Mask:255.255.255.0
eth0:1 Link encap:Ethernet HWaddr 00:50:BF:16:11:61
inet addr:192.168.0.21 Bcast:192.168.0.255 Mask:255.255.255.0
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
nmap --iflist before this commit:
DEV (SHORT) IP/MASK TYPE UP MAC
eth0 (eth0) 192.168.1.21/24 ethernet up 00:50:BF:16:11:61
eth0:1 (eth0) 192.168.0.21/24 ethernet up 00:50:BF:16:11:61
DST/MASK DEV GATEWAY
192.168.1.0/24 eth0
192.168.0.0/24 eth0
nmap --iflist after this commit:
DEV (SHORT) IP/MASK TYPE UP MAC
eth0 (eth0) 192.168.1.21/24 ethernet up 00:50:BF:16:11:61
eth0:1 (eth0) 192.168.0.21/24 ethernet up 00:50:BF:16:11:61
DST/MASK DEV GATEWAY
192.168.1.0/24 eth0
192.168.0.0/24 eth0:1
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.
