<div dir="ltr"><div>><span style="font-size:12.8000001907349px">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?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">No, it's not quite that bad. You still have to be plugged into net1. </span>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Does that make sense?</div><div><br></div><div>><span style="font-size:12.8000001907349px">The paragraph above is a bit obscure to me.</span><br></div><div><br></div><div>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.</div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><span class="im" style="font-size:12.8000001907349px"></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 4:07 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Kevin,<span class=""><div><br></div><div>On 8 June 2015 at 23:52, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br></div></span><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>There is a bug in security groups here: <a href="https://bugs.launchpad.net/neutron/+bug/1359523" target="_blank">https://bugs.launchpad.net/neutron/+bug/1359523</a></div><div><br></div><div>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:</div><div><br></div><div>create two networks with same <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a></div><div>create port1 in SG1 on net1 with IP 10.0.0.1<br></div><div>create port2 in SG1 on net2 with IP 10.0.0.2</div><div>create port3 in SG2 on net1 with IP 10.0.0.2</div><div>create port4 in SG2 on net2 with IP 10.0.0.1</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>port1 can communicate with port3 because of the allow rule for port2's IP</div><div>port2 can communicate with port4 because of the allow rule for port1's IP</div></div></blockquote><div><br></div></span><div>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?</div><div><br></div><div>The scenario you're describing is quite concerning from a security perspective. Shouldn't there be L2 isolation to prevent something like this?</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>The paragraph above is a bit obscure to me.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>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 <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> (for v4).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Implement address scopes.</div></div></blockquote><div><br></div><div>Sure, my master. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>Cheers!</div><span class="HOEnZb"><font color="#888888"><span><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></font></span></div><span class="HOEnZb"><font color="#888888">
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></font></span></blockquote></div><br></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>