Message-ID: <4E5F65AA.80004@mh-sec.de>
Date: Thu, 01 Sep 2011 12:59:54 +0200
From: Marc Heuse <mh@...sec.de>
To: Fernando Gont <fgont@...networks.com>, 
	Full Disclosure <full-disclosure@...ts.grok.org.uk>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: HP A-series switches are affected,
 too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]


Am 01.09.2011 12:10, schrieb Fernando Gont:
> On 09/01/2011 06:32 AM, Dan Luedtke wrote:
>> you addressed a problem that many vendors suffer from at the moment.
>> Marc Heuse discovered this vulnerability, i guess, 
> 
> FWIW, "publicly-released first" != "discovered" (ask Cisco's PSIRT if in
> doubt) -- anyway, I'm just trying to trigger discussion and get feedback...

when I reported to PSIRT they were not aware of the issue - so who
called them first is unsettled :-) - however I published first ;-)

> Anyway... I'd bet that every implementation that "followed" the spec is
> vulnerable....

it is not mentioned in the RFC that an interface does have to support
unlimited autoconfigurated addresses on its interfaces, nor does it
state an upper limit. so its undefined and up to the implementor. And
those who thought about it and saw the DOS coming (Solaris, OpenBSD) put
limits, others didnt (everybody else).

>> If you are interested, you can obtain my thesis as PDF-document here
>> https://www.danrl.de/dl/bachelor-thesis-luedtke.pdf
>> (Chapter Edge-Level might be the one of your interest)

@dan: nice paper.
ScreenOS has several DOS issues in their IPv6 implementation btw

>> By the way, I don't think it is a good idea to disallow any Extension
>> Headers in ND-Messages, 
> 
> Consensus at the relevant IETF working-group (6man) seems to be to only
> ban the Fragment Header (when SEND is not employed).

not allowing ANY extension headers for NDP and RA is the way to go. But
of course, doing this might break future features. Thats the reason that
only the fragment header is planned to be banned. Networking people
usually win over security people.

> A more conservative approach would be to simply require that the
> upper-layer header be present in the first fragment. (i.e., that the
> first fragment contains all the information that you need to apply an ACL).

and this is easily bypassed by overlapping fragments.
All current operating systems allow overlapping fragments, Windows,
OpenBSD, ... all.
I know there is an RFC which forbids overlapping fragments, but nobody
is implementing it.

>> I'd like switches to discard ND-Messages with
>> more that e.g. 3 chained headers. 
> 
> The point was that this could be expensive (if at all possible) for the
> RA-Guard implementation to do.

the main problem for RA guard is that it *requires the clients to change
their behaviour to be effective*:
 - drop overlapping fragments
 - drop RAs and NDPs which have extension headers / are fragmented

and this will not be happening soon, if ever.
so until then, RA guard is reliability feature (prevent accidential RAs,
e.g. by connection sharing of a Laptop) and no security feature.
But of course a good way for Cisco et.al. to make money.

Greets,
Marc

--
Marc Heuse
Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de

Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin

Ust.-Ident.-Nr.: DE244222388
PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists