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

[David Fifield <david () bamsoftware com>]

On Thu, Jun 09, 2011 at 08:50:21AM -0500, Daniel Miller wrote:
> 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.

I don't like this automatic conversion to IPv4-mapped addresses. I'd
prefer 1.2.3.4 and ::ffff:1.2.3.4 to compare different, and for one
address family to always sort before the other. How about just prefixing
each binary string with a byte indicating the address family, and then
doing a binary comparison?

left = "\x04" .. ip_to_bin(left)
left = "\x06" .. ip_to_bin(left)

as appropriate. It should have the same output as sockaddr_storage_cmp
in Nbase.

Let me know if you think differently, otherwise all this is fine to
commit with Patrik's later patches.

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