[NSE][patch] Bug in broadcast-dns-service-discovery and dnssd.lua

[Daniel Miller <bonsaiviking () gmail com>]

Hey list,

I've been playing with IPv6 scanning, and I discovered a bug when 
running the broadcast-dns-service-discovery script with the -6 flag:
> $ nmap --script broadcast-dns-service-discovery.nse -6 -d
>
> Starting Nmap 5.52.IPv6.Beta2 ( http://nmap.org ) at 2011-06-09 08:24 CDT
> Warning: File ./nmap-services exists, but Nmap is using 
> /usr/local/bin/../share/nmap/nmap-services for security and 
> consistency reasons.  set NMAPDIR=. to give priority to files in your 
> local directory (may affect the other data files too).
> PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0)
> --------------- Timing report ---------------
>   hostgroups: min 1, max 100000
>   rtt-timeouts: init 1000, min 100, max 10000
>   max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
>   parallelism: min 0, max 0
>   max-retries: 10, host-timeout: 0
>   min-rate: 0, max-rate: 0
> ---------------------------------------------
> NSE: Loaded 1 scripts for scanning.
> NSE: Starting runlevel 1 (of 1) scan.
> NSE: Starting broadcast-dns-service-discovery.
> NSE: Script Pre-scanning.
> Initiating NSE at 08:24
> NSE: Finished broadcast-dns-service-discovery.
> NSE: Finished broadcast-dns-service-discovery.
> NSE: dns.findNiceAdditional() found zero answers in a response, but 
> got an unexpected flags.replycode
> NSE: dns.findNiceAdditional() found zero answers in a response, but 
> got an unexpected flags.replycode
> NSE: dns.findNiceAdditional() found zero answers in a response, but 
> got an unexpected flags.replycode
> NSE: dns.findNiceAdditional() found zero answers in a response, but 
> got an unexpected flags.replycode
> NSE: broadcast-dns-service-discovery threw an error!
> /usr/local/bin/../share/nmap/nselib/dnssd.lua:53: attempt to perform 
> arithmetic on local 'o1' (a nil value)
> stack traceback:
>     /usr/local/bin/../share/nmap/nselib/dnssd.lua:53: in function 
> 'ipToNumber'
>     /usr/local/bin/../share/nmap/nselib/dnssd.lua:62: in function 
> </usr/local/bin/../share/nmap/nselib/dnssd.lua:61>
>     [C]: in function 'sort'
>     /usr/local/bin/../share/nmap/nselib/dnssd.lua:392: in function 
> 'queryServices'
>     ...are/nmap/scripts/broadcast-dns-service-discovery.nse:52: in 
> function <...are/nmap/scripts/broadcast-dns-service-discovery.nse:48>
>     (tail call): ?
>
> Completed NSE at 08:24, 7.25s elapsed
> NSE: Starting runlevel 1 (of 1) scan.
> Read from /usr/local/bin/../share/nmap: nmap-services.
> WARNING: No targets were specified, so 0 hosts scanned.
> Nmap done: 0 IP addresses (0 hosts up) scanned in 7.61 seconds

So I dug into it and found that dnssd.lua and wsdd.lua both had a custom 
ipCompare function used for sorting IPv4 addresses that couldn't handle 
IPv6 addresses. I rewrote them both to use ipOps.compare_ip(), but that 
function couldn't compare IPv4 to IPv6.

Based on some previous work with the Perl Nmap::Parser module, I patched 
ipOps to compare IPv4 to IPv6 by using IPv4-mapped IPv6 addresses. This 
involved adding a new function, ipOps.ip_to_str() that converts 
addresses to an opaque 4- or 16-byte string representation of the 
address, so that a straight string comparison could be done instead of 
the bit-by-bit comparison that was used before. This also simplified the 
logic for performing the proper comparison for the operator given.

The patch also makes a minor change to ntp-monlist to take advantage of 
IPv6 sorting. Even though v4 and v6 addresses can be sorted together 
now, I kept it separate to avoid breaking something, especially since 
the code involves column widths which vary from one to the other.

There was one more issue that I was not able to address: With the patch 
applied, broadcast-dns-service-discovery does not error out, but the 
results it returns are very strange:
> Pre-scan script results:
> | broadcast-dns-service-discovery:
> |   ::a00:8cee:0:0
> |     9/tcp workstation
> |       Address=192.168.1.14 2002:62be:b3c6:0:211:2fff:fed7:d902
> |     9/tcp workstation
> |       Address=192.168.1.17 2002:62be:b3c6:0:224:81fd:fe60:9b3
> |     9/tcp workstation
> |       Address=192.168.1.19 fe80:0:0:0:a800:4ff:fe01:a04
> |     9/tcp workstation
> |       Address=192.168.1.18 fe80:0:0:0:225:b3ff:fe6c:7986
> |   ::a00:c3e5:0:0
> |     22/tcp udisks-ssh
> |_      Address=192.168.1.18 fe80:0:0:0:225:b3ff:fe6c:7986
I can't explain those ::a00:XXXX:0:0 addresses. They change every time 
the script is invoked, but the results are always grouped according to 
port/service, rather than IP, as they should be.

Patch attached.
Dan

Attachment: ipv6.diff
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/