ICMPv6 RAs should only be permitted from known routers

[Ian Wells]

ICMPv6 is now allowed in from any host but other hosts can offer bogus routes.

Change security group/port filtering to respect known routers:

- tenant routers attached to subnets and passing v6
- physical routers on provider networks provided on the network (as some sort of admin configurable list for that network).

(Security issue: One VM sharing a neutron network can divert outgoing traffic from other VMs.)

[Jeremy Stanley (fungi)]

IETF RFC 6105 could be helpful reading here.

[Jeremy Stanley (fungi)]

http://ietf.org/rfc/rfc6105.txt

[Ian Wells (ijw-ubuntu)]

Fair point, that's a better answer on tenant networks. Provider networks would be tricker.

[Jeremy Stanley (fungi)]

As IPv6 routing is still in the process of being hashed out for Neutron, I don't think it's going to be helpful to keep this under embargo. Probably better to open it up and bring it to the attention of the Neutron IPv6 working group so that they'll be sure to take it into account in their designs?

[Ian Wells (ijw-ubuntu)]

I'm on the ipv6 group and we have it in mind. We've done some work for provider networks already but tenant networks are yet to be dealt with.

[Mark McClain (markmcclain)]

I would agree that an embargo makes little sense here since the team is still in active development on v6 features.

[Thierry Carrez (ttx)]

Is this actually affecting only Icehouse ? Or does it also affect Havana ?

[Ian Wells (ijw-ubuntu)]

It does technically affect Havana as well, I think (and Grizzly, and Folsom) though I think I'd want to test to be certain. Havana has a bug that pretty much kills IP address autoassignment when you're using libvirt, but if you make an educated guess as to a statically configured subnet in use, or if you aren't using libvirt, you could probably do it.

[Ian Wells (ijw-ubuntu)]

Though thinking about it we probably don't pass icmpv6 by default - that's a Havana change - so it might happen only if ipv6 is disabled (!) in the cloud. I'll check with the guys.

[Sean M. Collins (scollins)]

It does not affect Havana - it is only Icehouse-1 of Neutron that is affected.

Commit cecd7591533e2c046aedba3b8e5d14a5b2fa7fe9 introduces the bug.

[Jeremy Stanley (fungi)]

If it doesn't affect any stable release, we don't need to issue an advisory. I'll mark this invalid for OSSA in that case, but we can revisit if you change your mind.

[Jeremy Stanley (fungi)]

Also, unless there are disagreements, I'll go ahead and switch this to public tomorrow.

[Ian Wells (ijw-ubuntu)]

Right, so the case you would need is:

1. neighbour discovery works
  - libvirt enables hairpinning of traffic which breaks ND, so it's safe in versions to Havana. This is being fixed now, so we need to ensure that RA receipt is blocked in Icehouse
 2. an RA can be sent and received - same icmpv6 blocks
  - icmpv6 filtering blocks RA packets so icmpv6 filering must be enabled, which implies that we're safe if ipv6 is on for the cloud

So in the case that you are /not/ using libvirt and you have /disabled/ ipv6, and cloud image in stock form will do ND correctly and receive the RA packet, and will then pass ipv6 traffic to the spoofing host. Also, if you're sharing a network with untrusted machines then accepting RAs is risky.

The underlying issue here is our policy on port filters. For traffic types we don't know about, we *pass* them. So, if we know about ipv6 we implement sensible security - but if we don't know about it (e.g. ipv6 off) then we pass all traffic.

[Jeremy Stanley (fungi)]

With my former ISP/cloud network engineer hat on, I'm not sure I completely agree with "block all traffic passing through the infrastructure unless you know what it is" since that's how we spent a decade or more having to hound service providers and equipment manufacturers to stop breaking VPNs when they blocked all IP protocols besides ICMP/UDP/TCP. Similar philosophies about ICMP types and IP options led to rampant MTU black holes, ECN not working on most of the Internet, et cetera. Postel's law: be conservative in what you do, be liberal in what you accept from others.

I do agree, though, that a control like "disable IPv6 support in my cloud network" ought to explicitly block all bare/unencapsulated IPv6 traffic (there's not much you can do about tunneled IPv6, nor should you try to unless you have a local policy that all manner of tunneled traffic is forbidden). Similarly, a security group or other packet filter which is intended to block everything with a default deny rule should block *everything* including traffic you don't support in other capacities.

[Thierry Carrez (ttx)]

+1 on making public since this only affects the release-under-development.

[Jeremy Stanley (fungi)]

I think Ian's point was that there is actually some risk in Havana and earlier, but it's configuration dependent and you need a fairly specific constellation of design choices in place in your cloud for this to be exploitable.

To summarize, most popular Linux distros (and quite a few other other operating systems) boot by default listening for IPv6 router advertisements. It's quite possible, depending on your configuration, that your bridge is not explicitly filtering these between different virtual machines (or possibly even between tenants if you're using a flat bridged network). An attacker's virtual machine could be configured to generate RAs, convincing other VMs in the local broadcast domain to add global IPv6 addresses with a network prefix specified by the attacker, and start using those global addresses to communicate via IPv6 (through the attacker's VM which might have something along the lines of a toredo tunnel to an external tunnel broker or other globally IPv6-connected system) to remote systems which publish AAAA RRs in DNS. This makes the attacker an effective MitM for some of the victim's traffic.

But I do think this is probably not something which is going to be easy to address in prior releases, and will thus not particularly benefit from embargo.

[Xu Han Peng (xuhanp)]

As we talked in yesterday's IPv6 sub-team meeting, current we have this patch allowing all the RA by default so VM can do SLAAC without any security group configuration:

https://review.openstack.org/#/c/53028

But what we need soon is to only allow RA from the internal and external routers instead of all the RA.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/72252

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/72252
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b7b0c7dbcd3e6754bc09b2fd75d888c41ae4aadb
Submitter: Jenkins
Branch: master

commit b7b0c7dbcd3e6754bc09b2fd75d888c41ae4aadb
Author: Xuhan Peng <email address hidden>
Date: Sun Feb 9 22:02:33 2014 -0500

    Permit ICMPv6 RAs only from known routers

    Currently ingress ICMPv6 RAs are permitted from any IPs by
    default to allow VMs to accept ICMPv6 RA from provider network.
    In this way, VM can accept RAs from attacker VM and configure
    a network prefix specified by the attacher VM.

    Remove permitting ICMPv6 RAs from any IPs and add security rule
    to only permit ICMPv6 RA from:

    1. If the port's subnet is configured with ipv6_ra_mode value
    (i.e.value is slaac, dhcpv6-stateful, or dhcpv6-stateless), RA
    is sending from dnsmasq controlled by OpenStack. In this case,
    allow RA from the link local address of gateway port (if the
    gateway port is created).

    2. If the subnet's gateway port is not managed by OpenStack, allow
    the ICMPv6 RA sent from the subnet gateway IP if it's a link local
    address. The administrator needs to configure the gateway IP as
    link local address in this case to make the RA rule work.

    Change-Id: I1d5c7aaa8e4cf057204eb746c0faab2c70409a94
    Closes-Bug: 1262759

[Openstack Gerrit (openstack-gerrit)]

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/88034