Re: Nmap: problem with UDP scanning and --ip-options

[David Fifield <david () bamsoftware com>]

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/