Open Stack

>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?

No, it's not quite that bad. You still have to be plugged into net1. The
two networks are not connected together via a tenant router. You could
assume that they each have their own tenant router each with a connection
to an external network.

What needs to happen is that ports from the same security group are being
created on two disjoint networks with overlapping address space. Then the
allow rules that correspond to ports on the opposite network will end up
allowing traffic on the current network from those addresses.

The issue is that an allow rule is added for each member port in a security
group, even if those networks are not reachable from the port that the rule
is being added to. That becomes a problem with overlapping IPs where the IP
address being allowed may actually belong to a different port.

Does that make sense?

>The paragraph above is a bit obscure to me.

Let me try again. We need a way to prevent rules from being installed that
reference other security group members that are unreachable. This is
because the unreachable members might have the same IP address as other
ports on your network.






On Mon, Jun 8, 2015 at 4:07 PM, Salvatore Orlando <sorlando at nicira.com>
wrote:

> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150608/4675aa96/attachment.html>