[ipv6hackers] Looking for feedback on subjective top list of IPv6 security issues

[Marc Heuse]

Hi guys,

sorry coming so late to the discussion, but I gave a training at
CanSecWest and then conference (and the parties ;-) ) ...


First: reacting to Cameron Byrne
(I guess I put your opinion to a deep black here where you rather see it
as shades of grey. sorry for that. I know a lot of network people who
actually swear that IPv6 is totally fine. So I have to make a point here)

> I believe most of these have ipv4 equivalents

some of them are. obviously. Fernando however clearly shows that others
are not. And of course it is.
IPv6 shares 99% of the IPv4 feature set, plus adds 20% more (put your
own percentage in here if you like), so math already tells you that
there are NEW risks in IPv6.

But what we must talk here is actually risk management. so:

1) Likelihood, Impact and Residual Risk

even where there are similarities or equivalents, its not "the same".
e.g. fragementation. the IPv4 risks are 100% applied to IPv6. however as
you can use multiple framentation headers and create very complex
packets (which all systems try to assemble - which surprises me), the
LIKELIHOOD of issues increases.

Additionally, lets have a look at NDP spoofing <=> ARP spoofing. yes.
very similar here. But because of the OVERRIDE flag, the game changes
here. Overwriting existing entries is possible and therefore this
increases the IMPACT.

Increased likelihoods and/or impacts for all issues that have IPv4
equivalents show that saying "uh, nothing new" is a very bad way of
approaching this. Rather a political smoke grenade to prevent people
questioning IPv6.

But the difference is also PREVENTION.
On IPv4 I can do ARP spoofing detection (ARP snooping) rouge DHCP
spoofing detection etc. - and its easy.
In IPv6 with extension headers and fragmentation (and depending on the
setup further tricks ;-) ) this is more expensive to do.

This increases the residiual risks you have with IPv6.
So, overall the risks are higher with IPv6.

Or - to put my impression of your argument simple: "what, you have a
grenade launcher? thats not new, its the same as the sharp sticks we
used since we lived in caves" ;-)


2) Maturity

maturity basically impacts like likelihood and impact values of risks,
however what I want to say here is rather that because IPv4
implementation were reviewed and re-reviewed for the last 20 year, it is
way more mature than IPv6 which is not only younger but also more complex.
It helps that today we learned from IPv4 and e.g. have lots of test
cases that can be migrated to be IPv6 test cases plus know more about
good testing and fuzzing.
But still - and the actually numbers show that (see in every one of my
presentations) - although IPv4 is wider deployed than IPv6, the number
of reported vulnerabilities are half.
So, IPv6 is less mature, which - again, - increases likelihood and impact.


3) Vendor reaction

whenever I found an issue in IPv4 and reported it, it got fixed.
This is very different to what I experience with IPv6.
It does not matter if its Microsoft, Juniper, FreeBSD - even OpenBSD!
... they see IPv6 of less as an issue so bugs are not fixed - and they
tell you so. The same issue you report for IPv4 and IPv6 is handled
differently.
And thats actually my major concern with IPv6.


So: IPv6 is a higher risk than IPv4.
Denying that is irrational and without proof.

But I see that as a motivator to kick vendors to do more in terms of
security. That why I applaude to Fernando creating tons of
drafts/potential-rfcs to improve the protocol.

Nothing will happen if you do not show the issues. So be truthful about
it, and constantly put you finger deeply into the wound.
This creates change. Denying the issue is not.



... and finally ... back to the original questions :-)

> 8)      ICMPv6 redirect spoofing

I actually found this not as much of an issue as I thought, at least
with current systems, e.g. for Linux it seems that the redirect is only
valid per session.
and for the attack itself, if you are already local, you can also play
other tricks like NDP spoofing, RA spoofing, etc. and get all traffic.

> 9)      MLD/MLDv2 attacks - I'm not very clear on dangerous attacks
> for this one...

I can shed some light here.
many router implementation suck here. flood them with random report/done
messages, or mld router advertisements/solicitation and you get 100%
cpu, 100% ram and/or crash.
even with firewalls (netscreen for example. uh, just remembering I never
told them that. because their security team was not interested in fixing
ipv6 bugs so I stopped telling them)

> 10)   "Discoverability" or the idea that you should use randomized
> addressing so as not to be discoverable from a "semi-intelligent"
> brute force scan (assuming you're not in DNS or some other registry)

well this is only an issue where do do not want hosts to be found. and
the we are not talking about a security issue but an obscurity issue.
my recommendation: do not think of /64 giving your security. you never
know how an attacker is able to figure out what the address of your
precious host is.

> 11)   Extension header attacks - this one is especially tough,
> probably lots more to find...  I especially like Marc's warp packets
> with the router alert "high speed tag" which also double as ACL
> bypass agents.

yeah, that was so much fun ... :-)
actually I did not find a lot of issues here. as there are not that many
options yet, this is rather limited.
but fragementation headers plus extension headers - thats where it gets
scary (one of many examples, see my report on the Kaspersky remote freeze).

> 12)   Tunnel attacks - I think the only interesting ones would be
> those against 6in4, ISATAP, and 6rd as IMHO those are the only ones
> that are in use.  I have read about tunnel attacks but haven't played
> with this very much.  Do you think this is a serious threat worth
> covering?  Any suggestions on tools?

gladly I see little use of tunnels. and the risk is limited if you give
what comes out of the tunnel no trust.
if you use them and want security, you have to secure them with IPSEC.

I agree with Fernando that another important vector is the VPN dual
stack leakage issue. However I would expand on this and say that any
IPv4-only-thought-of network and dual stack networks pose a risk as the
complexity increases massively when both a present in the same network.
Either go IPv4 only (means: disabling IPv6 everywhere) or IPv6 only is
my recommendation. Doesnt make sense everywhere though.

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A