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-next>] [day] [month] [year] [list]
Message-ID: <4E5F5A13.4050707@si6networks.com>
Date: Thu, 01 Sep 2011 07:10:27 -0300
From: Fernando Gont <fgont@...networks.com>
To: Dan Luedtke <maildanrl@...glemail.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)]

Hi, Dan,

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



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

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


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

Will certainly take a look. Thanks!



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

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


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


> But that is another conversation...
> I subscribed to the IPv6 Hackers mailing list, maybe we will have some
> discussion about that over there.

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

Thanks!

Best regards,
-- 
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ