Open Stack

Kevin,

On 8 June 2015 at 23:52, Kevin Benton <blak111 at gmail.com> wrote:

> There is a bug in security groups here:
> https://bugs.launchpad.net/neutron/+bug/1359523
>
> In the example scenario, it's caused by conntrack zones not being
> isolated. But it also applies to the following scenario that can't be
> solved by zones:
>
> create two networks with same 10.0.0.0/24
> create port1 in SG1 on net1 with IP 10.0.0.1
> create port2 in SG1 on net2 with IP 10.0.0.2
> create port3 in SG2 on net1 with IP 10.0.0.2
> create port4 in SG2 on net2 with IP 10.0.0.1
>

> port1 can communicate with port3 because of the allow rule for port2's IP
> port2 can communicate with port4 because of the allow rule for port1's IP
>

So this would be a scenario when bug 1359523 hits even with conntrack zone
separation, with the subtle, and terrible difference that there is a way to
enable cross-network plugging? For instance to reach port1 on net1, all I
have to do is create a network with a CIDR with some overlap with net1's,
and then wait until a VM is created with an IP that exists also on net1 -
and then jackpot, that VM will basically have access to all of net1's
instances?

The scenario you're describing is quite concerning from a security
perspective. Shouldn't there be L2 isolation to prevent something like this?

The solution will require the security groups processing code to understand
> that a member of a security group is not actually reachable by another
> member and skip the allow rule for that member.
>

The paragraph above is a bit obscure to me.


>
> With the current state of things, it will take a tone of kludgy code to
> check for routers and router interfaces to see if two IPs can communicate
> without NAT. However, if we end up with the concept of address-scopes, it
> just becomes a simple address scope comparison.
>

This is fine, but I wonder how's that related to what you described
earlier. Is the vulnerability triggered by the fact that both networks can
be attached to the same router? In that case I think that if the l3 mgmt
code works as expected it would reject adding an interface for a subnet
with an overlap with another already attached subnet, thus implementing an
implicit address scope of 0.0.0.0/0 (for v4).


>
> Implement address scopes.
>

Sure, my master.

>
>
> Cheers!
> --
> Kevin Benton
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/07f4ef8c/attachment.html>