looked like:
./configure: line 6651: syntax error near unexpected token `in'
./configure: line 6651: ` for ac_header in'
configure: error: ./configure failed for libpcap
Example: http://seclists.org/nmap-dev/2010/q1/444
The problem is a bogus empty test in the libpcap/configure.in. It
was actually fixed by libpcap in SVN back in 2008, but there hasn't
been a release since then :(. They seem to still be actively developing,
just not making releases. Sigh.
before starting. There is a special function that does a trace of
directly connected targets without sending any packets, just by filling
in one hop directly to the target. The traceroute code was only checking
whether the first target in the group was directly connected, and if it
was, it assumed all of them were. Now it filters the list into two and
calls traceroute_direct on one and traceroute_remote on the other.
Fyodor discovered this problem today.
smtp-enum-users.method script argument was changed to
smtp-enum-users.methods and now takes an array. 252 and 550 error codes
are handled now. In verbose mode, the method used is included in the
output.
slower one-at-a-time enumeration method that has proved to be more
robust. Other changes:
- Fixes the "malformed packet" bug.
- Treats RSTs as rejections, not fatal errors.
- Adds some obsolete ciphers that were requested.
- SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
- SSL_RSA_FIPS_WITH_DES_CBC_SHA
- Adds some other cipher definitions.
- TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
- TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA
- TLS_DHE_DSS_WITH_RC4_128_SHA
- TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
- TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
- TLS_RSA_EXPORT1024_WITH_RC4_56_MD5
- TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
gather round-trip times for each port. The script then uses these
times to group together ports with statistically equivalent RTTs.
Ports in different groups could be the result of things such as port
forwarding to hosts behind a NAT. This is based on work by Doug
Hoyte. [Kris]
nfs-showmount scripts to use the new library. The new scripts are:
- nfs-acls shows the owner and directory mode of NFS exports
- nfs-dirlist lists the contents of NFS exports
- nfs-statfs shows file system statistics for NFS exports
[Patrik]
retest the zombie proxy and reinitialize all of the associated data
at the beginning of each run. [Kris]
The underlying code checking for this and for changing proxies goes all the
way back to r1486 (2002) and presumably before, but lastproxy was never filled
in and so was nonfunctional.
faithwriters, hotmail, myspace, phpbb, and rockyou. I kept the output at
200 lines for now until we have more comprehensive limits on the unpwdb
module.
The only password that didn't come straight out of the databases was the
empty password. I added it manually at the top. The previous version of
passwords.lst had it too.
and l_decrypt. Otherwise, OpenSSL reads unallocated memory:
openssl.encrypt("DES", "key", "iv", "datadatadatadata")
==5691== Invalid read of size 1
==5691== at 0x412F07D: DES_set_key_unchecked (in /usr/lib/libcrypto.so.0.9.8)
==5691== Address 0x4bcc415 is 2 bytes after a block of size 19 alloc'd
==5691== at 0x402598A: malloc (vg_replace_malloc.c:195)
==5691== by 0x4025A16: realloc (vg_replace_malloc.c:476)
==5691== by 0x80ED502: luaM_realloc_ (in /home/david/nmap/nmap)
==5691== by 0x80F134B: luaS_newlstr (in /home/david/nmap/nmap)
==5691== by 0x80F85FA: luaX_newstring (in /home/david/nmap/nmap)
==5691== by 0x80F8FF6: llex (in /home/david/nmap/nmap)
==5691== by 0x80F9861: luaX_next (in /home/david/nmap/nmap)
==5691== by 0x80EDCAF: testnext (in /home/david/nmap/nmap)
==5691== by 0x80EF718: explist1 (in /home/david/nmap/nmap)
==5691== by 0x80EF7C0: funcargs (in /home/david/nmap/nmap)
==5691== by 0x80EFA1C: primaryexp (in /home/david/nmap/nmap)
==5691== by 0x80EEE16: subexpr (in /home/david/nmap/nmap)
o [Ncat] The HTTP proxy server now accepts client connections over
SSL. That means connections to the proxy can be encrypted and
authenticated. We haven't found any HTTP clients that directly
support SSL connections to proxies, but you can use Ncat as a tunnel
to an SSL-supporting Ncat proxy. This new feature was implemented by
Markus Klinik.
to verify their correctness and to check more than just the table in
ipv4-address-space. Beyond comment changes and some code movement:
* 198.51.100.0/24 and 203.0.113.0/24 are reserved by RFC5737 (Jan 2010)
* Fix 198.18.0.0/15, which was implemented wrongly. This goes back a while
and was handled somewhat like 198.18.0.0/18.
is used. See discussion at http://seclists.org/nmap-dev/2010/q1/837.
In this patch, all output formats are treated the same. So if a host
isn't shown in normal output, it's not shown in XML output either.
DLT_LINUX_SLL, as well as the DLT_EN10MB that was formerly supported.
This type is used on some interfaces where Linux doesn't reliably retain
the link-layer header, and when capturing on the "any" device. On such
interfaces, you would get the error
read_arp_reply_pcap called on interfaces that is datatype 113 rather than DLT_EN10MB (1)
For more on this datalink type, see
pcap-linktype(7)
http://wiki.wireshark.org/SLL
I tested this by hacking scan_engine.cc to use the "any" device:
--- scan_engine.cc (revision 16972)
+++ scan_engine.cc (working copy)
@@ -4882,7 +4882,7 @@
}
}
- USI->pd = my_pcap_open_live(Targets[0]->deviceName(), 100, (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2);
+ USI->pd = my_pcap_open_live("any" /*Targets[0]->deviceName()*/, 100, (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2);
if (USI->ping_scan_arp){
/* Some OSs including Windows 7 and Solaris 10 have been seen to send their
ARP replies to the broadcast address, not to the (unicast) address that
I had to use a newer version of libpcap from git. The 1.0.0 that we ship
has a bug that keeps "any" from working. You would get SIOCGIFHWADDR: No
such device.
table is exactly the same as the address. This is how it appears to work on Mac
OS X. Now there are three ways for an address to be directly connected:
1. Gateway address is 0.0.0.0 (Linux).
2. Gateway address is the same as local interface address (Windows).
3. Gateway address is the same as the destination address (Mac OS X).
interface addresses and netmasks.
Before, route_dst worked like this:
1) Check destination address against all interfaces, with special-case
handling for local addresses.
2) Check destination address against routing table.
Now it works like this:
1) Check destination address against local addresses.
2) Check destination address against routing table.
3) Check destination address against all interfaces.
This allows a routing table entry to override an interface, for example
in this configuration:
************************INTERFACES************************
DEV (SHORT) IP/MASK TYPE UP MAC
eth0 (eth0) 192.168.0.21/24 ethernet up 00:00:00:00:00:00
**************************ROUTES**************************
DST/MASK DEV GATEWAY
192.168.0.3/32 eth0 192.168.0.1
192.168.0.0/24 eth0
192.168.0.3 will not be considered directly connected, but will have its
traffic routed through 192.168.0.1.
The logic for determining when an address is directly connected has
changed. Instead of considering an address directly connected whenever
it matches an interface netmask, we consider it so when the gateway
address is 0.0.0.0 or when the gateway address is exactly equal to the
interface address. The proper way to do this would be to look at the "G"
flag from the routing table, but libdnet doesn't retain that.
This establishes a more regular syntax for some options that disable
phases of a scan:
-n no reverse DNS
-Pn no host discovery
-sn no port scan
Also, the -sP was possibly misleading because the 'P' suggests "ping
scan," when you can now do more than just pinging when you disable port
scanning. For example, -sC -sn and -sn -Pn --traceroute make sense.
being used, and this leaves the door open for non-Ethernet encapsulation
of ARP packets, in particular the Linux "cooked" socket encapsulation
that can in some cases be used by libpcap.
counts. Brandon reported this assertion failure when running http-enum:
nmap: nsock_core.c:199: socket_count_write_dec: Assertion `(iod->writesd_count) > 0' failed.
The problem was that handle_write_result always assumed that if a call
to SSL_write failed with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
that it must have been invoked because the socket was writable (and
hence the write count should be decremented). Because of how
non-blocking sockets work in OpenSSL, it's possible that we called
handle_write_result because a socket because *readable* and thus we
should decrement the read count, not the write count.
