full-disclosure - Re: HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAfuxnJW6Ot79VC+2q-H0_-deJCyR1qQxHctqVsZv=_Tp0OXSA@mail.gmail.com>
Date: Thu, 1 Sep 2011 12:44:57 +0200
From: Dan Luedtke <maildanrl@...glemail.com>
To: Fernando Gont <fgont@...networks.com>
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)]

Hello Fernando,

On Thu, Sep 1, 2011 at 12:10 PM, Fernando Gont <fgont@...networks.com> wrote:
>> Based on Marc's ideas I tested the mentioned attack on Hewlett
>> Packard's A-series switches, and I have to say that these attacks were
>> successful. That stopped us from implementing IPv6 for a while in our
>> network.
>
> Do they ship with "RA-Guard"? -- Note that "hosts being vulnerable to
> RA-based attacks" does not imply a vulnerable RA-Guard implementation.
> The layer-2 might simply not ship with RA-Guard, it could ship with it
> but not be enabled, etc.
I have to admit, I was a little bit sloppy about the term RA-Guard.
Every vendors has another name for the feature that *should* provide
protection from faked Router Advertisements, technically it is
sometimes like RA-Guard, in reality it is often a simple ACL wrapped
in a shiny new command. HP tried to implement it in their "Neighbor
Discovery Detection" feature of Comware, and they succeeded partly.
One has to craft some nasty packets to circumvent their protection,
but one still is able to do so.


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

>> 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).
I'd like to discuss this further, there are many options and I really
like to read other's opinions on that. Disallowing Fragmentation
Headers might break some stack implementations (but hopefully only in
some situations). On the other hand, (virtually) reassembling IPv6
packets on a layer2 device is expensive.

I'll have a look on ipv6-hackers as soon as I am back from vacation.

> Yep... will post something right now, and see if that triggers discussion.
Thanks!

regards,
   danrl
-- 
danrl / Dan Luedtke
http://www.danrl.de

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