[OpenIndiana-discuss] Fwd: [discuss] IPv6 bogus Router Advertisements and Illumos 5729

Jon Tibble meths at btinternet.com
Sat Mar 28 20:56:36 UTC 2015

-------- Forwarded Message --------
Subject: [discuss] IPv6 bogus Router Advertisements and Illumos 5729
Date: Fri, 27 Mar 2015 14:51:26 -0400
From: Dan McDonald <danmcd at omniti.com>
Reply-To: discuss at lists.illumos.org
To: Dan McDonald <danmcd at omniti.com>

Hello folks!

This is being sent to the illumos developers' list, the illumos 
discussion list, and the OmniOS discussion list.  I'd appreciate if 
folks from other distros please forward this to your appropriate distro 
mailing list(s).  This mail assumes a mild working knowledge of IPv6 and 
of the illumos kernel's internal structures.  If you have questions, 
feel free to contact me.  The bottom line is we have nothing to worry 
about!  The rest of this note explains why.

Recently, I pushed this seemingly innocuous fix into illumos-gate:

commit a36f6bde69ea4d4ea2b0a475ce962b9c1c4ef323
Author: Dan McDonald <danmcd at omniti.com>
Date:   Thu Mar 19 19:04:20 2015 -0400

     5729 in.ndpd should log broken RAs
     Reviewed by: Robert Mustacchi <rm at joyent.com>
     Approved by: Gordon Ross <gordon.w.ross at gmail.com>

I did so in response to a no-longer-embargoed request from CERT.  The 
problem behavior manifests with a malicious on-link IPv6 attacker who 
can theoretically cause nodes to lower their default IPv6 hop limit 
(like IPv4's TTL) to a small enough amount where IPv6 packets get 
dropped before they reach their destinations.

This attack does not affect illumos, nor has it ever since its 2010 
inception.  This is due to our unusual STORAGE of IPv6 Router 
Advertisement hop limits, vs. where we actually set these defaults.

Our in.ndpd code sends a SIOCLIFLNKINFO ioctl to the kernel in response 
to a changed hop limit via a Router Advertisement.  Fortunately, our 
kernel stores this information in an ill_t's ill_max_hops.  To see 
these, per-interface, utter this as root on your system's global zone:

   echo "::walk ill | ::print ill_t ill_name ill_isv6 ill_max_hops" | mdb -k

The default value is "0", meaning use a system default.  The good news 
is, the value is NEVER USED BY THE REST OF THE IPv6 STACK.  IPv6 instead 
always sets the hopcount for locally-originated, non-reflective, packets 
to whatever these ndd(1M) variables are set, per netstack:

	ndd -get /dev/{tcp,udp,icmp} {tcp,udp,icmp}_ipv6_hoplimit

You can use the above mdb(1) walker to see if one of your subnets has 
been subject to lower IPv6 hoplimits via Router Advertisements.  An RA 
message with that field set to 0 means don't change, and that's what 
usually is sent.  If it's set to any other of 1-255, the ill_max_hops 
field will reflect the most recent receipt of this.  If you have 
multiple nics on multiple subnets (zoned or non-zoned) you may see 
varying values.

Apparently some other platforms act on RA hop limits more aggressively 
than illumos does.  They are fixing this problem.  Starting with the fix 
for 5729, we are more vocal about seeing such RA hop limits, and have 
"mdb -p `pgrep in.ndpd`" tunable globals to help sysadmins detect such 

I will now quote from CERT:

Essentially, RFC 3756 <https://www.ietf.org/rfc/rfc3756.txt> Section 4.4 
lists some possible attacks that can be done regarding router discovery 
operations in IPv6. The reporter's attack appears to be a variant of 
these already well-known attacks. This fake RA attack in IPv6 has been 
compared to ARP poisoning in IPv4. In other words, this is a known 
problem due to rogue nodes on an internal network, and likely not a 
severe software vulnerability as originally thought. CERT/CC thanks 
vendors that helped provide this analysis.

Furthermore, this information was also submitted by the reporter to 
several public mailing lists before contacting us. For example, see 
discussion is available at <http://patchwork.ozlabs.org/patch/453995/> 
and <http://www.spinics.net/lists/netdev/msg322327.html>. Therefore, 
information on this patch is already fairly public at this point.

Given the circumstances, we will therefore remove our embargo, and allow 
vendors to address this issue more publicly if desired.

So if you see a CERT notice about IPv6 Router Advertisements and hop 
limits appear in the near future, you know that I've already performed 
our due diligence on this account.

For the record, I'm now officially a CERT point of contact, so I see 
things like this occasionally.  I hope to do right by illumos with this 
responsibility.  In the future, if I have a problem that I need help 
with, I know I can count on the community to help.  (Some of you already 
have helped, and without throwing you under the bus, THANK YOU!)

Happy IPv6-ing!
Dan McDonald -- OmniOS Engineering

Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: 
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com

More information about the openindiana-discuss mailing list