yahoo-eng-team team mailing list archive

[Jeremy Stanley <fungi@xxxxxxxxxxx>]

Since you mention this may be a security vulnerability (potential denial
of service attack) in a supported release, I've switched the bug from
public to public security and added an OSSA task in case it warrants an
advisory.

** Information type changed from Public to Public Security

** Also affects: ossa
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1322945

Title:
  Attaching a IPv6 private subnet to a L3 Router, breaks it and its IPv4
  Floating IPs

Status in OpenStack Neutron (virtual network service):
  New
Status in OpenStack Security Advisories:
  New

Bug description:
  Hey Stackers!

  I think I found a serious BUG in Neutron...

  When a regular user from random a OpenStack Project, creates a static
  IPv6 subnet, from within its own account, and attach it to its L3
  Router, then, it breaks the IPv4 Floating IPs at the Network Node for
  an entire OpenStack installation (Region / AZ), making it unusable,
  plus, that External Network (that one where the Floating IPs come
  from) breaks too, it becomes impossible to delete it.

  Here is how I'm reproducing it:

  
  1- Install OpenStack IceHouse with Ubuntu 14.04, using the topology "Per-Project Router with Private Networks";

  2- Logged with "admin" user, create a Shared Public IPv4 External
  Network as usual (http://docs.openstack.org/icehouse/install-
  guide/install/apt/content/neutron_initial-external-network.html);

  3- Logged as a Project (#1) regular user (i.e. not admin), create its
  Network as usual, Router attached to the shared External Network,
  private IPv4 subnet attached to its Router. Example:
  http://i.imgur.com/lauqDUQ.png ;

  4- Still logged as a regular user at Project #1, creates an IPv6
  subnet to its private net (like 2008:129:2bf:cd1::/64), with DHCP
  disabled, no DNS Servers (example: neutron subnet-create --ip-version
  6 --disable-dhcp --tenant-id $PROJECT1_TENANT_ID privatenet1
  2008:129:2bf:cd1::/64) - Example: http://i.imgur.com/tPQX21E.png ;

  5- Allocate a couple Floating IPs for Project #1;

  6- Create a Instance and attach a Floating IPv4 to it, test it (it
  works as expected). Working Example: http://i.imgur.com/xE5brug.png ;

  7- Attach the "Project Router" to the tenant IPv6 private subnet
  (source of the BUG?) = http://i.imgur.com/WfTzpOl.png &
  http://i.imgur.com/sRAhA6P.png ;

  8- Create a new ("dual-stacked") Instance;

  9- Here comes the BUG side effects: try to attach an IPv4 at this
  "dual-stacked" Instance (using IPv4 ports, of course), it will not
  work! The Floating IPv4 seems to be attached but, the IP does not
  appear at its L3 Router (Network Node Project Namespace Router) as
  expected!

  9.1- The IPv4 Floating IP 172.20.0.6 (attached after adding "Router
  #1" to the IPv6 subnet), did not appeared at the L3 Router. Details:
  http://i.imgur.com/QFSOa3T.png &
  http://paste.openstack.org/show/81401/ ;

  
  From this point, the Floating IPs from External Network stops working for the entire cloud (Region / AZ)!

  Also, it is impossible to clean it up, by deleting the external
  network, it will not work, triggering the following error:
  http://paste.openstack.org/show/81402/

  I know that IPv6 isn't officially supported by OpenStack but, my point
  is that a regular user can literally breaks the L3 Router by simple
  adding a innocent IPv6 subnet to its Router, affecting all other
  tenants (it effectively breaks the External Network that belongs to
  the "admin" user). So, because of this, I'm also marking this as a
  security vulnerability.

  Regards,
  Thiago

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1322945/+subscriptions