Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Gervais Arthur <arthur.gervais@insa-lyon.fr>
Cc: Jan Ceuleers <jan.ceuleers@computer.org>, netdev@vger.kernel.org
Subject: Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets
Date: Sat, 07 May 2011 15:25:58 +0200	[thread overview]
Message-ID: <1304774758.2821.1237.camel@edumazet-laptop> (raw)
In-Reply-To: <dc9a790de083b31ff85c0b9578c980e7@mail.insa-lyon.fr>

Le samedi 07 mai 2011 à 15:17 +0200, Gervais Arthur a écrit :
> On 05/07/2011 03:10 PM, Eric Dumazet wrote:
> > Le samedi 07 mai 2011 à 14:55 +0200, Jan Ceuleers a écrit :
> >> 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<arthur.gervais@insa-lyon.fr>
> >> To:<linux-kernel@vger.kernel.org>
> >> CC:<arthur.gervais@insa-lyon.fr>
> >>
> >> [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)
> >>
> >
> > 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.
> 

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 ?




  reply	other threads:[~2011-05-07 13:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-07 12:55 Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets Jan Ceuleers
2011-05-07 13:05 ` Gervais Arthur
2011-05-07 13:10 ` Eric Dumazet
2011-05-07 13:17   ` Gervais Arthur
2011-05-07 13:25     ` Eric Dumazet [this message]
2011-05-07 13:54       ` Gervais Arthur
2011-05-07 14:06         ` Eric Dumazet
2011-05-07 14:35           ` Gervais Arthur
2011-05-10 11:14             ` wanq
2011-05-07 14:21         ` Mikael Abrahamsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1304774758.2821.1237.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=arthur.gervais@insa-lyon.fr \
    --cc=jan.ceuleers@computer.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox