Re: Possible bug in IPv6 ND Ping Scan

[Xu Weilin <mzweilin () gmail com>]

Hi, Luis,

Thanks for your care.

On Tue, Aug 16, 2011 at 7:16 PM, Luis MartinGarcia. <luis.mgarc () gmail com>wrote:

> **
> Hi,
>
> I was running Nmap 5.59BETA1 against an IPv6 target and I noticed that the
> BPF filter for the ND ping scan may not work in all cases. I get this (I've
> removed many useless output):
>
> luis@Aberdeen:~$ sudo nmap -6 fe80::20c:29ff:fe80:2b01 -d
>
> Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2011-08-16 13:05 CEST
> Initiating ND Ping Scan at 13:05
> Scanning fe80::20c:29ff:fe80:2b01 [0 ports]
> Packet capture filter (device vmnet1): icmp6 and ip6[6:1] = 58 and
> ip6[40:1] = 136
> Completed ND Ping Scan at 13:05, 0.05s elapsed (1 total hosts)
> Initiating SYN Stealth Scan at 13:05
> Scanning fe80::20c:29ff:fe80:2b01 [1000 ports]
> Packet capture filter (device vmnet1): dst host fe80::250:56ff:fec0:1 and
> (icmp or icmp6 or ((tcp or udp or sctp) and (src host
> fe80::20c:29ff:fe80:2b01)))
>
>
> The problem is in the BPF for the ND Ping scan. It currently uses "icmp6
> and ip6[6:1] = 58 and ip6[40:1] = 136". I think it is wrong because it
> assumes that no extension headers are present in the response. While right
> now it is very very uncommon to find systems that use extension headers, it
> may not be that uncommon in the future. In my opinion, the BPF filter should
> be modified to work in all cases. I dunno what's the best approach. A simple
> bpf="icmp6" might do the trick but I doubt that libpcap traverses the whole
> list of extension headers to determine if there is an ICMPv6 header in a
> captured packet. Maybe we should simply use "ip6" and implement our own
> filter in the pcap handler. What do you guys think?

Yes, the current BPF string is not perfect though it works well at the
moment. "icmp6" couldn't help to solve the problem also, since libpcap is
designed not to traverse the list of extension headers. You are right, the
best way is to use "ip6" and implement the ICMPv6 ND filter in the pcap
handler. But I wouldn't like to implement this right now. The problem caused
by the extension headers affects all the IPv6 pcap handlers so that we
should have a universal solution.


> Another thing: about the second filter, the one for the SYN scan, why is
> there "icmp"? Do we expect any type of ICMPv4 response when we are sending
> IPv6 datagrams?

The code is not written by me, but I don't think it has something wrong.
Whether 'icmp' or 'icmp6' makes sense depends on the address family of the
specified host. In this way, the string without addresses can be shared by
both address families, which makes the code more clear.

-- 
Regards
Xu Weilin 许伟林
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/