Message-ID: <4E5F6C04.2020004@si6networks.com>
Date: Thu, 01 Sep 2011 08:27:00 -0300
From: Fernando Gont <fgont@...networks.com>
To: Marc Heuse <mh@...sec.de>
Cc: 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)]

Hi, Marc,

On 09/01/2011 07:59 AM, Marc Heuse wrote:
>> 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 ;-)

Again, please ask PSIRT. :-)

In any case, the world doesn't (or "shouldn't", at least) care about the
"who", but rather should care about the "what".



>> 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. 

I was referring to the RA-Guard spec (RFC6105), and not the SLAAC spec.


> 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).

One could argue that good programming practice means that you enforce
limits on everything. That said, I agree that implementation advice is
strongly needed.



>>> 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.

mmm... not really so. Bob Hinden himself seemed to be in favor of baning
all of them..



>> 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.

Agreed.


> 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.

IIRC, both Linux and Windows 7 do.



>>> 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.

Please see:
http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt

It doesn't require any modifications at the client (assuming it
completely bans fragmented RAs).



> so until then, RA guard is reliability feature (prevent accidential RAs,
> e.g. by connection sharing of a Laptop) and no security feature.

As noted in my blog post, curiously enough the problem statement
(RFC6104) is about accidental RAs, while the RA-Guard "spec" itself aims
to be a "security device".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@...networks.com
web: http://www.si6networks.com



_______________________________________________
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