IP address for a router interface allowed outside the allocation range of subnet

Bug #1757482 reported by Kenneth Peeples on 2018-03-21
294
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Security Advisory
Undecided
Tony Breeds
neutron
High
Miguel Lavalle

Bug Description

Currently running Queens on Ubuntu 16.04 with the linuxbridge ml2 plugin with vxlan overlays. We have a single, large provider network that we have set to 'shared' and 'external', so people who need to do things that don't work well with NAT can connect their instances directly to the provider network. Our 'allocation range' as defined in our provider subnet is dedicated to tenants, so there should be no conflicts.

One of our users connected a neutron router to the provider network (not via the 'external network' option, but rather via the normal 'add interface' option) and neglected to specify an IP address. The neutron router decided that it was now the gateway for the entire provider network and began arp'ing.

This seems like it should be disallowed inside of neutron (you shouldn't be able to specify an IP address for a router interface that isn't explicitly part of your allocation range on said subnet). Unless neutron just expect issues like this to be handled by the physical provider infrastructure (spoofing prevention, etc.)?

tags: added: router
tags: added: provider

Thanks for reporting the issue. I suspect the issue should not be limited to linuxbridge. One part that's not clear is the sequence of commands you chose to plug the logical router on the network. If that was done through the CLI and using the add-interface command, that takes either a specific port or a subnet. In the latter case the IP ends up being auto-allocated from within the IP allocation pool. In the former case, that can be overridden but then it feels like the harm is somewhat self-inflicted?

Please consider providing more details so that it can help the triage efforts!

Thanks

tags: added: api l3-ipam-dhcp
removed: provider router
Changed in neutron:
status: New → Incomplete
Kenneth Peeples (kpeeples) wrote :

Armondo I will work on providing more detail for the issue. Received the below from Kevin Benton through the mailing list so wanted to add to the bug for additional feedback.

I think you might have uncovered an edge-case that should probably be filed as a bug against Neutron. If a router interface is attached using a reference to a subnet, it always tries to use the address in the "gateway_ip" of the subnet:
https://github.com/openstack/neutron/blob/282d3da614f24a6385c63a926a48845d3f6d72a3/neutron/db/l3_db.py#L797-L798

My opinion is that Neutron probably shouldn't allow grabbing the default gateway if you aren't the owner of the subnet, but that is a fix that might not land for a while depending on their priorities.

In the meantime, I recommend that you create a neutron port as an admin on the public network using the gateway_ip of the network to represent your real gateway router. This will prevent anyone from being able to attach a router using the subnet as a reference since the gateway_ip address will already be in use.

Chris Apsey (bitskrieg) wrote :

All,

Want to provide some more detail here:

Let's say for example we create our provider network with the follow CLI command:

openstack subnet create --network public --allocation-pool start=10.50.20.0,end=10.50.255.100 --dns-nameserver 10.50.255.254 --gateway 10.50.255.254 --subnet-range 10.50.0.0/16 public_subnet

One would imagine that tenants (who are not in the owning admin project) would not be able to allocate IP addresses to instances, routers, etc. that fall outside of the allocation range, so commands sequences such as:

openstack port create --fixed-ip ip-address=10.50.255.254 --network public foo-port
openstack router create bar-router
openstack router add port bar-router foo-port

would fail. As of now, they do not, and users can successfully create a port outside of the allocation range on networks they do not own. This can present a possible DoS condition as described above (unless the workaround described above is implemented, e.g. 'openstack port create --disable --fixed-ip ip-address=10.50.255.254 --network public dummy-public-gateway-port' as an admin.

I realize that we are accepting some risk by allowing users to create ports directly on the public network, but I do feel it is a valid use case, and neutron should not allow users to create ports on a network they do not own that is outside of the prescribed allocation range, much in the same way that neutron checks the db for already-allocated addresses before port creation. Applying the same logic would fix the issue from our perspective.

Chris Apsey (bitskrieg) wrote :

Also, want to add that the 'public' network in the above example was created in this manner, with the external and shared flags set:

openstack network create --external --share --provider-physical-network provider --provider-network-type flat public

Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
Brian Haley (brian-haley) wrote :

Re-opened since bug 1774019 seems to be a duplicate. In that case a user was able to add a router to a shared external network and it got the .1 address. Looks like there is an edge case here we need to cover.

Changed in neutron:
status: Expired → Confirmed
importance: Undecided → High
Miguel Lavalle (minsel) on 2018-05-31
Changed in neutron:
assignee: nobody → Miguel Lavalle (minsel)
Jeremy Stanley (fungi) wrote :

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

information type: Public → Public Security
Changed in ossa:
status: New → Incomplete
Ian Kumlien (pomac) wrote :

I completely agree with the comments from the reporter.

If you can specify a ip outside the range then you can ruin all kinds of things and cause major havock - even as just a user on the cloud with no special permissions.

I tested this seems like need to address another issue as comment 3 mentioned,
i created another subnet on public net with allocation_pools | {"start": "10.50.20.0", "end": "10.50.255.100"}

then I was able to create port with fixed ip that was out of pool range.
it allowed to add that port to router interface.

I guess it shouldn't have let me create an port with ip out of pool range in first place, if I am correct.
this happens only for provider subnet. below is paste of all the command I ran and output.

http://paste.openstack.org/show/722991/

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

Changed in neutron:
status: Confirmed → In Progress

Reviewed: https://review.openstack.org/575444
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=54aa6e81cb17b33ce4d5d469cc11dec2869c762d
Submitter: Zuul
Branch: master

commit 54aa6e81cb17b33ce4d5d469cc11dec2869c762d
Author: Miguel Lavalle <email address hidden>
Date: Thu Jun 14 09:21:09 2018 -0500

    Disallow router interface out of subnet IP range

    Currently, a non privileged tenant can add a router interface to a
    shared / external network's subnet with an IP address outside the
    subnet's allocation pool, creating a security risk. This patch prevents
    tenants who are not the subnet's owner or admin from assigning a router
    interface an IP address outside the subnet's allocation pool.

    Change-Id: I32e76a83443dd8e7d79b396499747f29b4762e92
    Closes-Bug: #1757482

Changed in neutron:
status: In Progress → Fix Released
tags: added: neutron-proactive-backport-potential

Reviewed: https://review.openstack.org/584324
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8287d7f546e4ffe7a2ac32df50d6b465484f81cc
Submitter: Zuul
Branch: stable/queens

commit 8287d7f546e4ffe7a2ac32df50d6b465484f81cc
Author: Miguel Lavalle <email address hidden>
Date: Thu Jun 14 09:21:09 2018 -0500

    Disallow router interface out of subnet IP range

    Currently, a non privileged tenant can add a router interface to a
    shared / external network's subnet with an IP address outside the
    subnet's allocation pool, creating a security risk. This patch prevents
    tenants who are not the subnet's owner or admin from assigning a router
    interface an IP address outside the subnet's allocation pool.

    Change-Id: I32e76a83443dd8e7d79b396499747f29b4762e92
    Closes-Bug: #1757482
    (cherry picked from commit 54aa6e81cb17b33ce4d5d469cc11dec2869c762d)

tags: added: in-stable-queens
Tony Breeds (o-tony) on 2018-07-23
Changed in ossa:
assignee: nobody → Tony Breeds (o-tony)
status: Incomplete → Triaged

This issue was fixed in the openstack/neutron 13.0.0.0b3 development milestone.

Reviewed: https://review.openstack.org/584326
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c1d2f13495b2eb925be6495840795ead5929fd0e
Submitter: Zuul
Branch: stable/ocata

commit c1d2f13495b2eb925be6495840795ead5929fd0e
Author: Miguel Lavalle <email address hidden>
Date: Thu Jun 14 09:21:09 2018 -0500

    Disallow router interface out of subnet IP range

    Currently, a non privileged tenant can add a router interface to a
    shared / external network's subnet with an IP address outside the
    subnet's allocation pool, creating a security risk. This patch prevents
    tenants who are not the subnet's owner or admin from assigning a router
    interface an IP address outside the subnet's allocation pool.

    Change-Id: I32e76a83443dd8e7d79b396499747f29b4762e92
    Closes-Bug: #1757482
    (cherry picked from commit 54aa6e81cb17b33ce4d5d469cc11dec2869c762d)

tags: added: in-stable-ocata

Reviewed: https://review.openstack.org/584325
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=988eceac27a9ad91775376b3b3fedf84963663a5
Submitter: Zuul
Branch: stable/pike

commit 988eceac27a9ad91775376b3b3fedf84963663a5
Author: Miguel Lavalle <email address hidden>
Date: Thu Jun 14 09:21:09 2018 -0500

    Disallow router interface out of subnet IP range

    Currently, a non privileged tenant can add a router interface to a
    shared / external network's subnet with an IP address outside the
    subnet's allocation pool, creating a security risk. This patch prevents
    tenants who are not the subnet's owner or admin from assigning a router
    interface an IP address outside the subnet's allocation pool.

    Change-Id: I32e76a83443dd8e7d79b396499747f29b4762e92
    Closes-Bug: #1757482
    (cherry picked from commit 54aa6e81cb17b33ce4d5d469cc11dec2869c762d)

tags: added: in-stable-pike

This issue was fixed in the openstack/neutron 12.0.4 release.

This issue was fixed in the openstack/neutron 11.0.6 release.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers