BugTraq
Re: [Full-disclosure] HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)] Sep 01 2011 10:10AM
Fernando Gont (fgont si6networks com) (2 replies)
Re: [Full-disclosure] HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)] Sep 01 2011 10:59AM
Marc Heuse (mh mh-sec de) (1 replies)
Re: [Full-disclosure] HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)] Sep 01 2011 11:27AM
Fernando Gont (fgont si6networks com)
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 (at) si6networks (dot) com [email concealed]
web: http://www.si6networks.com

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus