Changed two existing match lines to softmatches as they were triggering against messages instructing the client to change protocols to SSL. This was preventing nmap from checking the service on SSL as it though a match was found. See http://seclists.org/nmap-dev/2013/q1/280
We never intend to ask for a service on a port other than the one we
connect to. By my reading of RFC 2616 section 14.23, we can leave the
port number off in this case. Robin Wood reported that
https://twitter.com/ gives you a redirect instead of a page if you send
it
Host: twitter.com:443
rather than
Host: twitter.com
http://seclists.org/nmap-dev/2013/q1/267
This prevents potentially reading (and buffering) every input host while
looking for more targets to fill up the current hostgroup. One of the
criteria that can split hostgroups is interface. Suppose you have an
input list of targets whose interfaces are
eth0 eth0 eth0 wlan0 wlan0 wlan0 wlan0 wlan0 wlan0...
The first three eth0 will go in the first group, and then the following
wlan0 will start to be buffered while we look for more eth0. But we will
only look ahead 64 targets, then go ahead and scan the three eth0.
This allows some targets to be skipped over yet remembered so they can
be dealt with later. The idea is that because ping groups are not
allowed
to have duplicate IPs, we continue searching for non-duplicates in order
to fill up a ping group, then return to what were formerly duplicates.
This prevents potentially large ping groups from being split into small
groups.
For example, if the list of targets is
A B C D A B E A F G
the ping groups used to be
(A B C D) (A B E) (A F G)
but now they are
(A B C D E F G) (A B) (A]
A similar thing can be done for port scan hostgroups, but this already
does most of the work because ping groups are generally bigger than
hostgroups and have pretty much the same restrictions.
Apparently SCTP can't have the same kind of half-open sockets that TCP
has. When one direction is closed, we can't do anything further with the
socket.
http://seclists.org/nmap-dev/2013/q1/227
This eliminates the ambiguity that could exist when, say, both o.udp and
o.sctp were both set. The code would use whichever it happened to test
first. This also makes TCP mode explicit with IPPROTO_TCP.
At high scan rates, there was nothing to prevent trying to set or clear
socket descriptors above FD_SETSIZE, which is usually around 1024. I got
a reliable assertion failures with the command
nmap -sT -p- --min-rate 100000 scanme.nmap.org
The problem only affected -sT scans. A similar protection was added to
Nsock in r15808.
Fixed a bug that prevented Nmap from finding any interfaces when one
of them had the type ARP_HDR_APPLETALK; this was the case for
AppleTalk interfaces. However, This support is not complete
since AppleTalk interfaces use different size hardware addresses
than Ethernet. Nmap IP level scans should work without any problem,
please refer to the '--send-ip' switch and to the following thread:
http://seclists.org/nmap-dev/2013/q1/214
This bug was reported by Steven Gregory Johnson on IRC.
Compare to this similar test in Nmap's scan_engine.cc:
if (scantype != CONNECT_SCAN && Targets[0]->ifType() == devt_loopback) {
log_write(LOG_STDOUT, "Skipping %s against %s because Windows does not support scanning your own machine (localhost) this way.\n", scantype2str(scantype), Targets[0]->NameIP());
return;
}
rndbit made a report--unfortunately we con't fix it, but we can make the
error message clearer.
http://seclists.org/nmap-dev/2013/q1/187
Nping calls route_dst at least twice: once with a NULL device, and again
with the device learned from the first time. This interfered with the
code that automatically chooses a loopback interface for dests that are
the same as an interface address. For example, if you are 192.168.0.1,
and you are scanning 192.168.0.1, route_dst will tell you to use
interface "lo0" even though the interface of 192.168.0.1 may be "eth0".
route_dst was returning failure because the device name check was being
done before "eth0" got changed to "lo0".
This problem didn't show up on Linux because Linux uses
route_dst_netlink, which delegates the work to the kernel. But I could
reproduce on Linux by forcing the use of route_dst_generic.
The existing tests here didn't make much sense, and didn't cover all the
situations we care about. The 8 tests now check each of
client !--send-only EOF on stdin
client --send-only EOF on stdin
server !--send-only EOF on stdin
server --send-only EOF on stdin
client !--recv-only EOF on socket
client --recv-only EOF on socket
server !--recv-only EOF on socket
server --recv-only EOF on socket
The other thing we care about is whether the client/server keeps running
after the EOF. That is now checked in each of the tests too.
RFC 3986 section 3.1:
Although schemes are case-insensitive, the canonical form is lowercase
and documents that specify schemes must do so with lowercase letters.
An implementation should accept uppercase letters as equivalent to
lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the
sake of robustness but should only produce lowercase scheme names for
consistency.
