Security Group doesn't work if the specific allowed-address-pairs value is set

[Danil Akhmetov]

Summary:

Security Group doesn't work if the specific allowed-address-pairs value is set to the port associated with it.

High level description:

OpenStack user is allowed to specify arbitrary mac_address/ip_address pairs that are allowed to pass through a port. For some practical reasons, OpenStack users can specify huge subnets, and CIRDs provided there are not sanitized. If the CIRD provided with 'allowed-address-pairs' for any single port associated with Security Group overlaps with a subnet used by the VM, the VM is always accessible by any port and any protocol, despite the fact that its security group denies all ingress traffic.

Step-by-step reproduction process:

1) Create a VM in OpenStack
2) Check that there are no rules allowing icmp (for instance) in the security group associated with the VM
3) perform:
neutron port-update [any-port-associated-with-the-secgroup] --allowed-address-pairs type=dict list=true ip_address=[a-very-huge-cidr]

if your VM uses a private IPv4 address from networks 192.168.x or 172.16.x, then 128.0.0.0/1 will work as "a-very-huge-cidr", if it uses 10.x network then 0.0.0.0/1 should.

4) ping all the VMs in this secgroup successfully (from router namespace, or from any host which is allowed to access floating IPs if floating IP is also assigned to the VM), as well as access it by any port and protocol which the VM is listening.

Version:

All OpenStack releases up to Mitaka.

Perceived severity:

It's not a blocker as workaround are pretty obvious, but it's a huge security bug: all the network security provided by Security Groups might be ruined easily, just by updating a single port in neutron.

If we restrict the value of allowed-address-pairs in neutron to a single address (/32 or /128), might it break anything?

[Sean M. Collins (scollins)]

Don't mark it as confirmed please, allow the bug liaison to triage - I think they use the New status to filter bugs

[Akihiro Motoki (amotoki)]

My colleague hit this as an operator too. I will check what actually happens.

[Danil Akhmetov (dinobot)]

the issue happens when the CIDR which is overlapping with a VM appears in ipset (so only the configuration which is using ipset for Security Groups is affected)

[Hirofumi Ichihara (ichihara-hirofumi)]

I can reproduce it in my env.

[Ann Taraday (akamyshnikova)]

On my environment I was able not only reproduce this issue, but moreover if I add allowed pair address for one address this address became available for all vm in this security group.
http://paste.openstack.org/show/589594/. I will investigate this more.

[Ann Taraday (akamyshnikova)]

Actually problem appears for security groups which has allowed pair address on port with big cidr as remote security group. As default security group has itself as remote security group this simply reproduced with it.

And some more: to have ping for all VMs from in that security group you need to have rule that allow ICMP(or any) for that remote security group. (we have this from the beginning in default security group)

Here is paste http://paste.openstack.org/show/589868/

All of this look really weird to me. Probably, solution here is create separate ipset for allowed pair addresses. I will try come up with a patch shortly.

[Kevin Benton (kevinbenton)]

This is the way allowed address pairs intentionally behaves. If you have a security group rule allowing traffic from ports in a particular security group ID and one of those ports is allowed to send traffic from a ton of IP addresses, all of those IP addresses will match the rule.

I think we probably need some more documentation in the security groups section of the manual[1] that emphasizes this point. If you are going to use allowed address pairs that allow huge CIDRs, it's probably a good idea to remove the port from any security groups.

Changing this behavior would be a breaking change, so I'm not sure there is much we can do about it.

1. http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/intro-os-networking.rst#n224

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/404792
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Armando Migliaccio (armando-migliaccio)]

As Kevin said.