Reported here: http://seclists.org/nmap-dev/2014/q3/137
Hostgroups should have a common outgoing interface and source address,
determined by target_needs_new_hostgroup. Source address for raw IP
probes (sendIPScanProbe) is taken from the list of decoys (o.decoys),
which always at least contains a "self" element at index o.decoyturn.
This element was not being set while filling a hostgroup for massping,
so it was using whatever the value from the last hostgroup had. This
only matters when mixing targets that require different source
addresses, as demonstrated by scanning localhost and some other address.
branch-reset patterns (?|...) were introduced in Perl 5.10.0, but some
folks complained when their older PCRE libs crashed on this line.
This changes the use into a single outer capture, then uses the $P()
helper function to strip out the unprintable length bytes.
This was a case where order of arguments affected the outcome: if -PE
came before -Pn, then -Pn took precedence. Otherwise, -PE took
precedence (except that o.pingtype would also contain PINGTYPE_NONE...
not sure how that affected things). This cleans things up by letting
PINGTYPE_NONE be OR'd into o.opingtype, then checking for it after all
options have been processed and clearing out the other types if it is
found.
The TLS standard (TLS 1.2, but also probably the others) states:
> In the absence of an application profile standard specifying
> otherwise, a TLS-compliant application MUST implement the cipher
> suite TLS_RSA_WITH_AES_128_CBC_SHA
This was causing some problems with some implementations (See
http://seclists.org/nmap-dev/2014/q3/119)
Because of previous merging, some fingerprints had grown to encompass
others. Other fingerprints for the same or similar devices were close
enough that they could be merged. This was a manual review of 614
fingerprints that were identified as differing from some other
fingerprint by only the SEQ line (256 unique non-SEQ fingerprints).
The result: 44 fingerprints were merged into others, or were deleted
because they were a proper subset of some other fingerprint (e.g. Linux
2.6.17 that is not distinguishable from a broader Linux 2.6.11-2.6.32
fingerprint). A couple of these appeared to be identical copy-and-paste
errors in the past. I was very conservative in what I chose to merge,
choosing only the most-obvious fingerprint pairs that did not lose
information (e.g. not merging unrelated specialized devices, even if
their fingerprints were very close).
Doesn't happen often, but as the message says, certain Solaris zones can
cause problems here. This message is more informative than the previous
"socket troubles in Init"
This change restores the control flow of handling connect() return and
error values. This shouldn't result in any real changes, but makes it
simpler to see the differences introduced in r33185.
Some errors were not properly propagated. Ensure proxy_resolve() returns
a negative error code and make the caller fatal() when unable to complete
proxy_chain initialization for whatever reason.
Since the refactor in r33185, getting a good response for a host during
a ping scan can remove all outstanding probes for that host, since we
already know the host is up. This broke the existing iteration in some
cases. I could force the crash with: nmap -sn -PS80-89 scanme.nmap.org
Now we check explicitly for an empty list each time through the loop.
Consolidate connect-scan status and errno checking
Previously, the return value and socket errors from the connect() call
were checked in two different places: immediately after the call, and
then later as the sockets were select()ed over. This led to a divergence
of logic, so the immediate checking failed to set state reasons or
contribute to timing. This commit puts all such checking into a single
function, handleConnectResult, so further improvements will not diverge
again.
Previously, the return value and socket errors from the connect() call
were checked in two different places: immediately after the call, and
then later as the sockets were select()ed over. This led to a divergence
of logic, so the immediate checking failed to set state reasons or
contribute to timing. This commit puts all such checking into a single
function, handleConnectResult, so further improvements will not diverge
again.
In sendConnectScanProbe, the usual method is to start a non-blocking
connect() and then do select() on the sockets until we get a result. On
some platforms and in some circumstances, connect() either blocks or
comes back immediately. We handled this by setting the port state
appropriately, but we didn't set the reason, yielding results like "Host
is up, received no-response" and "80/tcp open http no-response"
