IPv6 OS fingerprinting crashes on Ubuntu/Debian with UFW enabled

[Daniel Miller <bonsaiviking () gmail com>]

Hi, List,

This took me a while to track down. The crash:

$ sudo ./nmap -6 -Pn -n -O -p 80,81 scanme.nmap.org -d

Starting Nmap 6.45 ( http://nmap.org ) at 2014-08-03 03:17 UTC
--------------- 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
---------------------------------------------
Initiating SYN Stealth Scan at 03:18
Scanning scanme.nmap.org (2600:3c01::f03c:91ff:fe93:cd19) [2 ports]
Packet capture filter (device eth0): dst host <MY_IPV6_ADDR> and (icmp or
icmp6 or ((tcp or udp or sctp) and (src host
2600:3c01::f03c:91ff:fe93:cd19)))
Discovered open port 80/tcp on 2600:3c01::f03c:91ff:fe93:cd19
Completed SYN Stealth Scan at 03:18, 0.08s elapsed (2 total ports)
Overall sending rates: 26.05 packets / s, 1667.51 bytes / s.
Starting IPv6 OS Scan...
[FPEngine] Interface=eth0 BPF:dst host <MY_IPV6_ADDR> and (src host
2600:3c01::f03c:91ff:fe93:cd19)
sendto in send_ipv6_ipproto_raw: sendto(6, packet, 80, 0,
2600:3c01::f03c:91ff:fe93:cd19, 28) => Operation not permitted
Offending packet: ICMPv6 (58) <MY_IPV6_ADDR> >
2600:3c01::f03c:91ff:fe93:cd19 (type=128/code=0) hopl=56 flow=12345
payloadlen=40

The cause (Note that I don't know why the first ACCEPT rule doesn't take
precedence):

$ sudo ip6tables -n -L
<snip>
Chain ufw6-before-output (1 references)
target     prot opt source               destination
ACCEPT     all      ::/0                 ::/0
DROP       all      ::/0                 ::/0                 rt type:0
segsleft:0
<snip>

The fix (comment out the offending rule):

sudo sed -i '/ufw6-before-output -m rt --rt-type 0/s/^/#/'
/etc/ufw/before6.rules
sudo ufw reload

What is really happening? The IE2 probe [1] is setting a Routing Type 0
IPv6 extension header, which is basically source routing, and therefore
"bad." UFW (an iptables rule manager developed for Ubuntu but ported to
other Linux distros) has decided that the filtering of this header should
be applied to outgoing as well as incoming and forwarded packets. This
manifests as an EPERM error in sendto() when we try to send a packet with
this header. Note that Nmap isn't trying to actually *do* source routing.
The extension header is crafted to not actually include any intermediate
addresses, and explicitly states (with a 0x00 byte) that there are no more
Segments Left to modify the route, so according to RFC 2460 [2], the header
should be ignored.

So what can be done (besides requiring users to modify their firewall
rules)? I see a few options:

1. Handle the error more gracefully. Perhaps we skip this probe, just like
we skip some probes when we can't find an open or a closed TCP port. It
will result in less-accurate fingerprints, but will probably still have
lots to work with (e.g. all the TCP probes).

2. Modify the probe. This may invalidate (or at least skew) our existing
fingerprints database, though. We could use a non-0 routing type (0, 1, and
2 are valid, all others must be ignored, provided the Segments Left is 0,
according to the RFC, but I'd be willing to bet some implementation will
respond with ICMP errors instead). Or we could drop this header, since it's
probably not the source of differentiating responses (the duplicate
hop-by-hop header is what makes IE2 "special"). This header is also
probably causing packets to be filtered at other network points like ISP
gateways, so we may get better results after modifying it.

3. Do nothing and handle bug reports as they trickle in. This rule has been
in UFW since 0.30.1, which was added to the Ubuntu repositories in March
2011, so I'm very surprised we haven't gotten a bug report yet. On the
other hand, this is probably due to limited IPv6 connectivity, so we can
expect to see more problems with this.

Dan

[1] http://nmap.org/book/osdetect-ipv6-methods.html#osdetect-ipv6-methods
[2] http://tools.ietf.org/html/rfc2460#section-4.4
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/