Nmap Development mailing list archives
Re: Nmap: problem with UDP scanning and --ip-options
From: David Fifield <david () bamsoftware com>
Date: Wed, 8 Jun 2011 17:18:24 -0700
On Tue, Jan 11, 2011 at 06:36:30PM +0100, Bogdan wrote:
Hello everybody. I have a problem with nmap. It goes like this: when I scan a closed UDP port with no IP options, nmap sends one UDP packet, gets one packet back (ICMP destination unreachable, port unreachable), determines that the port is closed and shows the port as closed in the results (with reason port-unreachable). Now, when I scan the same port with any IP options ("--ip-options U" is the easiest), nmap sends 2 UDP packets (like it got no response for the first), gets two ICMP packets back, but shows the port as open|filtered (like it got no response). Enabling debug mode shows: Received short ICMP packet (86 bytes). The total IP length in the received packets is set to 92 (20 for IP, 8 for ICMP, 20+36 for the erroneous packet with the options and 8 for the UDP header) and this should be the expected length. But the received packet isn't shorter, as nmap would suggest. Wireshark recognises it easily.
Bogdan, please try the new version 5.52.IPv6.Beta2. I think this problem is fixed through more careful header parsing.
Moreover, there is a second problem with this scan: if the erroneous packet is artificially shortened to 28 bytes (20 for the shorter IP header, instead of 56, and 8 for UDP), it is recognised correctly and the port is marked as closed. But the RFC for ICMP says that the "Internet header" should be included in the ICMP destination-unreachable message. It doesn't say "The minimum Internet header", so I guess it should be the full header, even if it's longer that the minimum 20 bytes. The third problem: the shortened packet's checksums can be freely modified and nmap will still recognise the packet, parse it and mark the port as closed. Furthermore, rejecting incorrect ICMP packets is expected (incorrect both in terms of checksums and the fact that the ICMP packet did not contain the nmap's sent packet's header).
I'm not too worried about receiving packets that are too short or have incorrect checksums. We should err on the side of matching broken packets, I think.
The last question: is there an "open bug list" for nmap? Searching the site and mailing lists on my question's topic didn't produce any results, so I'm not sure if I'm not sending a duplicate report for something already reported or marked as "not to be fixed".
The mailing list is the closest thing. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Nmap: problem with UDP scanning and --ip-options David Fifield (Jun 08)