Unless given a specific listen address, we open two separate listening
sockets, one for IPv4 and one for IPv6. It was previously a fatal error if we
failed to create either socket. Now it is fatal only when all potential
listening addresses fail.
David Millis discovered that the IPv6 listener failed on Windows XP without
IPv6 configured.
Ncat: socket: An address incompatible with the requested protocol was used. QUITTING.
http://seclists.org/nmap-dev/2013/q3/96
David Millis noticed this error on Windows XP with IPv6 disabled:
Ncat: Failed to resolve default IPv6 address: No such host is known. . QUITTING.
http://seclists.org/nmap-dev/2013/q3/96
Marin Maržić noticed that port.service is set even for unmatched
services. We want this script to run especially for ports 80 and 443.
http://seclists.org/nmap-dev/2012/q4/490
Apparently it only worked before when you were running from an Nmap
source directory, where nselib was in the current directory.
Roy Woods reported the problem.
http://seclists.org/nmap-dev/2013/q3/48
Having this entry made it appear as if there was a search criterion
named for the empty string; i.e., a string like ":foobar" would be
parsed as an operator "" with an argument "foobar". There was no match
function defined for the empty string, which led to this crash:
Version: 6.25
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/zenmapGUI/ScanInterface.py", line 247, in filter_hosts
self.inventory.apply_filter(filter_string)
File "/usr/lib/python2.7/dist-packages/zenmapCore/NetworkInventory.py", line 502, in apply_filter
if not self._match_all_args(host, operator, args):
File "/usr/lib/python2.7/dist-packages/zenmapCore/NetworkInventory.py", line 452, in _match_all_args
if positive != self.__getattribute__("match_%s" % operator)(host, arg):
AttributeError: 'FilteredNetworkInventory' object has no attribute 'match_'
I did some quick tests and plain keyword searching (with no colon) seems
to still work. I'm not sure why the "" entry was ever present.
Reported by Kris Paernell.
http://seclists.org/nmap-dev/2013/q3/38
If you ran the (fortunately non-default) http-domino-enum-passwords
script with the (fortunately also non-default)
domino-enum-passwords.idpath parameter against a malicious server,
it could cause an arbitrarily named file to to be written to the
client system. Thanks to Trustwave researcher Piotr Duszynski for
discovering and reporting the problem. We've fixed that script, and
also updated several other scripts to use a new
stdnse.filename_escape function for extra safety. This breaks our
record of never having a vulnerability in the 16 years that Nmap has
existed, but that's still a fairly good run. [David, Fyodor]
