Open Stack

>This sounds like a different bug than 1359523.

You're right, I just filed a bug for this:
https://bugs.launchpad.net/neutron/+bug/1463589

>Just curious has anyone hit this in the wild or is this totally contrived?

I initially contrived it, but it was also brought up to me a concern to me
from one of our in-house scalability testers. I highly doubt someone will
notice this in the wild because nothing loudly breaks. It just makes your
VMs vulnerable to unexpected connections.

>My first reaction to this is that if you set this up like this, you
deserve it.

No

>I'm not inclined to invest a lot of effort in to this.  I don't see it as
a big security hole.  Is there a way to exploit this that I cannot see?

If you have a large virtual topology and then have a couple of VMs attached
to a shared network that has overlapping addresses with anything in your
virtual topology, your VMs on the shared network will be vulnerable to
connections from anything that shares an address with the VMs on your
private topologies.

My example scenario in the previous email was more contrived to get to the
heart of the issue, but the above is a lot more likely to happen.

Our security group grouping model implies that you are allowing specific
neutron ports. That happens to be rendered into iptables rules based on the
IP addresses, which violates the API intent whenever ports land in
different overlapping subnets.

We can continue the discussion on the bug report.

On Tue, Jun 9, 2015 at 12:33 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:

> On Mon, Jun 8, 2015 at 3:52 PM, 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
>
> This sounds like a different bug than 1359523. It isn't what was described
> in the bug report and has a different underlying cause. While it looks
> similar on the surface, could we open up a new bug to track this?  Just
> curious has anyone hit this in the wild or is this totally contrived?
>
> My first reaction to this is that if you set this up like this, you
> deserve it.  Maybe we just advise that people plan to avoid scenarios that
> intersect multiple security groups across disparate L2 networks using
> overlapping IP address space.  Don't use overlapping subnets.  Or, if you
> do, don't use the same security group across them.  But, that is just a cop
> out if we haven't had a discussion.
>
> Using address scopes will prevent any overlap and fix this situation in
> the following way.  I think this is what Kevin had in mind:
>
> create two networks with same 10.0.0.0/24 allocating the subnets from an
> address pool.  They must be allocated from different subnet scopes.  We
> know because if they were the same scope, overlap wouldn't be allowed.  A
> fundamental design feature of address scopes is that address overlap is
> prevented within the scope.
>
>   Net1 has address scope a and net2 has address scope b.   All the subnets
> on a network from the same address family are required to be from the same
> pool.  Hence, they'll be in the same scope.
>
>   create port1 in SG1 on net1 with IP 10.0.0.1.  Has address scope a
>   create port2 in SG1 on net2 with IP 10.0.0.2.  Has address scope b
>   create port3 in SG2 on net1 with IP 10.0.0.2.  Has address scope a
>   create port4 in SG2 on net2 with IP 10.0.0.1.  Has address scope b
>
> The scope names are arbitrary and contrived but we know that port1 and
> port3 must be in the same scope because they are on the same network.  We
> also know that a != b because the same scope wouldn't allow the overlap.
>
> > 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
>
> These would be prevented if the security group code notices that port1 and
> port2 are not in the same scope and therefore will never be able to
> communicate without some sort of NAT in between.  It should leave out the
> allow rules because of this.
>
> Same for port3 and port4 in the other SG.
>
> > 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.
>
> I said the same thing just with a little more specificity and referring to
> the example.
>
> > 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.
>
> I'm not inclined to invest a lot of effort in to this.  I don't see it as
> a big security hole.  Is there a way to exploit this that I cannot see?
> I'm still inclined to say that we should come up with some kind of advise
> for how to manage SGs and networks to avoid it.
>
> > Implement address scopes.
>
> I will. Stay tuned.  I did not, however, include any kind of integration
> with security groups with my address scopes spec.  I don't think I should
> necessarily stop everything to include it either.  I still tend to think
> that this example is a bit contrived which is why I've asked if this was
> hit in the wild.
>
> You should keep in mind that address scopes will not be forced on anyone.
> You will get the same thing as today if you continue to make all the same
> API calls to set it up. Address scopes will only come in to play if you use
> subnet pools. If you don't use subnet pools, you can still create
> overlapping address ranges.  So, we can make security groups address scope
> aware but it won't fix the problem for existing models.
>
> Carl
>
> __________________________________________________________________________
> 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/20150609/d42c44ed/attachment.html>