default security group with multiple subnets can expose all services to internet

[Jake Hill]

The Default security group permits connections from other members via an ipset definition. In a project which has multiple networks/subnets, this ipset gets the following entries added;

  0.0.0.0/1
  128.0.0.0/1

Combined with a float IP assignment, the result is that all services are exposed to Internet regardless of all other security group policies applied.

Example Default security group definition;

routergod@juju:~/openstack-base$ openstack security group show b74db3fa-110c-4a69-81c7-c20eb268545f --format shell
created_at="2018-12-19T08:20:46Z"
description="Default security group"
id="b74db3fa-110c-4a69-81c7-c20eb268545f"
name="default"
project_id="be08d8a5ba844902927d14deb1aa1673"
revision_number="1"
rules="created_at='2018-12-19T08:20:46Z', direction='egress', ethertype='IPv4', id='14801bac-3519-411e-ba33-4b1321756d2b', updated_at='2018-12-19T08:20:46Z'
created_at='2018-12-19T08:20:46Z', direction='ingress', ethertype='IPv4', id='4b6bfdd4-366e-49cd-b3ff-323e33464750', remote_group_id='b74db3fa-110c-4a69-81c7-c20eb268545f', updated_at='2018-12-19T08:20:46Z'
created_at='2018-12-19T08:20:46Z', direction='ingress', ethertype='IPv6', id='6d0f6be0-3c10-46c1-a279-b79b55deef36', remote_group_id='b74db3fa-110c-4a69-81c7-c20eb268545f', updated_at='2018-12-19T08:20:46Z'
created_at='2018-12-19T08:20:46Z', direction='egress', ethertype='IPv6', id='eae8ef70-2ce9-486b-84ad-46cf09908ba8', updated_at='2018-12-19T08:20:46Z'"
updated_at="2018-12-19T08:20:46Z"

The ipset definition in the hypervisor;

root@oshv07:~# ipset list
Name: NIPv4b74db3fa-110c-4a69-81c7-
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 1688
References: 14
Number of entries: 22
Members:
192.168.4.7
192.168.4.11
192.168.4.14
192.168.4.36
192.168.4.35
192.168.4.15
192.168.4.26
192.168.4.27
192.168.2.19
192.168.4.46
192.168.4.28
128.0.0.0/1
192.168.4.13
192.168.1.5
192.168.4.10
192.168.4.22
0.0.0.0/1
192.168.4.30
192.168.4.20
192.168.4.19
192.168.4.16
192.168.4.25

This is a similar definition for a project where there is only one subnet;

Name: NIPv4b7c8d07b-d814-448d-88ac-
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 792
References: 7
Number of entries: 7
Members:
192.168.1.14
192.168.1.13
192.168.1.11
192.168.1.5
192.168.1.24
192.168.1.10
192.168.1.8

This has been verified on Mitaka with Linux Bridging and on Queens with OVS.

[Slawek Kaplonski (slaweq)]

Can You share exact steps to reproduce this issue? What networks and subnets You have created for tenant, what VMs You have created and so on.

I just tried to reproduce this issue on devstack with master branch. I had network with 2 IPv4 subnets but when I created vm connected to this network I didn't get such entries in ipset as You described above.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Jake Hill (routergod)]

Yeah I should have tried that. Turns out I have characterized this wrongly. The issue is not with multiple subnets, rather it is the use of;

  neutron port-update --allowed-address-pair ip_address=0.0.0.0/0 <port-id>

in relation to a port in the security group. I wonder if this may break any security group which refers to itself?

I reproduced as follows;

1. create network and /24 subnet
2. create small cirros instance on network
3. use 'openstack port list --server <id>' to determine the port-id
4. do ' neutron port-update --allowed-address-pair ip_address=0.0.0.0/0 <port-id>'
5. check the ipset

HTH!

[Jake Hill (routergod)]

I did follow this up on the bug tracker and didn't hear back - did you manage to reproduce? I realise the bug description is inaccurate, should I raise a new bug?

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Slawek Kaplonski
Sent: 01 April 2019 13:07
To: Hill,J,Jake,VQI R <email address hidden>
Subject: [Bug 1822572] Re: default security group with multiple subnets can expose all services to internet

Can You share exact steps to reproduce this issue? What networks and subnets You have created for tenant, what VMs You have created and so on.

I just tried to reproduce this issue on devstack with master branch. I had network with 2 IPv4 subnets but when I created vm connected to this network I didn't get such entries in ipset as You described above.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1822572

Title:
  default security group with multiple subnets can expose all services
  to internet

Status in neutron:
  New

Bug description:
  The Default security group permits connections from other members via
  an ipset definition. In a project which has multiple networks/subnets,
  this ipset gets the following entries added;

    0.0.0.0/1
    128.0.0.0/1

  Combined with a float IP assignment, the result is that all services
  are exposed to Internet regardless of all other security group
  policies applied.

  Example Default security group definition;

  routergod@juju:~/openstack-base$ openstack security group show b74db3fa-110c-4a69-81c7-c20eb268545f --format shell
  created_at="2018-12-19T08:20:46Z"
  description="Default security group"
  id="b74db3fa-110c-4a69-81c7-c20eb268545f"
  name="default"
  project_id="be08d8a5ba844902927d14deb1aa1673"
  revision_number="1"
  rules="created_at='2018-12-19T08:20:46Z', direction='egress', ethertype='IPv4', id='14801bac-3519-411e-ba33-4b1321756d2b', updated_at='2018-12-19T08:20:46Z'
  created_at='2018-12-19T08:20:46Z', direction='ingress', ethertype='IPv4', id='4b6bfdd4-366e-49cd-b3ff-323e33464750', remote_group_id='b74db3fa-110c-4a69-81c7-c20eb268545f', updated_at='2018-12-19T08:20:46Z'
  created_at='2018-12-19T08:20:46Z', direction='ingress', ethertype='IPv6', id='6d0f6be0-3c10-46c1-a279-b79b55deef36', remote_group_id='b74db3fa-110c-4a69-81c7-c20eb268545f', updated_at='2018-12-19T08:20:46Z'
  created_at='2018-12-19T08:20:46Z', direction='egress', ethertype='IPv6', id='eae8ef70-2ce9-486b-84ad-46cf09908ba8', updated_at='2018-12-19T08:20:46Z'"
  updated_at="2018-12-19T08:20:46Z"

  The ipset definition in the hypervisor;

  root@oshv07:~# ipset list
  Name: NIPv4b74db3fa-110c-4a69-81c7-
  Type: hash:net
  Revision: 6
  Header: family inet hashsize 1024 maxelem 65536
  Size in memory: 1688
  References: 14
  Number of entries: 22
  Members:
  192.168.4.7
  192.168.4.11
  192.168.4.14
  192.168.4.36
  192.168.4.35
  192.168.4.15
  192.168.4.26
  192.168.4.27
  192.168.2.19
  192.168.4.46
  192.168.4.28
  128.0.0.0/1
  192.168.4.13
  192.168.1.5
  192.168.4.10
  192.168.4.22
  0.0.0.0/1
  192.168.4.30
  192.168....

[Slawek Kaplonski (slaweq)]

Hi,

I checked that and indeed it is like You described. By adding 0.0.0.0/0 to allowed-addres pair it is added to ipset thus everything is matched to it and allowed.
So basically it is like SG would be disabled for such port.

But now there are 2 questions here:
1. Should it be treated as security bug? IMHO is something what user can make to his ports by his own. I isn't possible to add such allowed address pair by someone else.
2. Is it really a bug which should be fixed on neutron's side? Here also I'm not sure. IMHO it works like expected - when You are adding 0.0.0.0/0 to allowed addresses than traffic to such IP should be allowed. You should avoid adding such cidr to allowed address pairs.

So based on above points, I think that maybe we should better document this potential risk and that would be enough from neutron's side.
But I would also want to see what other neutron developers thinks about it.

[Brian Haley (brian-haley)]

I would agree with Slawek, adding 0.0.0.0/0 to the allowed address pair should be allowing all network traffic. It is essentially the same as creating an ingress security group rule for all IPs:

$ openstack security group rule create --ingress --protocol any --remote-ip 0.0.0.0/0 default

I think the best we can do is document it as a warning, in case it was unexpected, but we shouldn't disallow the 'any' IP from being specified.

[Slawek Kaplonski (slaweq)]

I just found that this is in fact duplicate of https://bugs.launchpad.net/neutron/+bug/1793029 - should we then make it public and mark as duplicate?

[Jeremy Stanley (fungi)]

Yes, this seems to be a duplicate. I'll switch it to public and mark it as such now.