From 1824248 at bugs.launchpad.net Mon Jul 1 02:47:38 2019 From: 1824248 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 01 Jul 2019 02:47:38 -0000 Subject: [Openstack-security] [Bug 1824248] Fix included in openstack/neutron 13.0.4 References: <155493822208.21486.11348171578680982627.malonedeb@soybean.canonical.com> Message-ID: <156194925817.30617.12107361425677165945.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/neutron 13.0.4 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1824248 Title: Security Group filtering hides rules from user Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Manage Rules part of the GUI hides the rules currently visible in the Launch Instance modal window. It allows a malicious admin to add backdoor access rules that might be later added to VMs without the knowledge of owner of those VMs. When sending GET request as below, it responds only with the rules that are created by user and this happens when using Manage Rules part of the GUI: On the other hand when using GET request as below, it responds with all SG and it includes all rules, and there is no filtering and this is used in Launch Instance modal window: Here is example of rules display in Manage Rules part of GUI: > /opt/stack/horizon/openstack_dashboard/dashboards/project/security_groups/views.py(50)_get_data() -> return api.neutron.security_group_get(self.request, sg_id) (Pdb) l  45 @memoized.memoized_method  46 def _get_data(self):  47 sg_id = filters.get_int_or_uuid(self.kwargs['security_group_id'])  48 try:  49 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  50 -> return api.neutron.security_group_get(self.request, sg_id)  51 except Exception:  52 redirect = reverse('horizon:project:security_groups:index')  53 exceptions.handle(self.request,  54 _('Unable to retrieve security group.'),  55 redirect=redirect) (Pdb) p api.neutron.security_group_get(self.request, sg_id) , , , ]}> (Pdb) (Pdb) p self.request As you might have noticed there are no ports access 44 and 22 (SSH) And from the Launch Instance Modal Window, as well as CLI we can see that there are two more rules that are invisible for user, port 44 and 22 (SSH) as displayed below: > /opt/stack/horizon/openstack_dashboard/api/rest/network.py(47)get() -> return {'items': [sg.to_dict() for sg in security_groups]} (Pdb) l  42 """  43  44 security_groups = api.neutron.security_group_list(request)  45 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  46  47 -> return {'items': [sg.to_dict() for sg in security_groups]}  48  49  50 @urls.register  51 class FloatingIP(generic.View):  52 """API for a single floating IP address.""" (Pdb) p security_groups [, , , , , ]}>] (Pdb) (Pdb) p request Thank you, Robin To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1824248/+subscriptions From 1824248 at bugs.launchpad.net Mon Jul 1 02:49:12 2019 From: 1824248 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 01 Jul 2019 02:49:12 -0000 Subject: [Openstack-security] [Bug 1824248] Fix included in openstack/neutron 14.0.2 References: <155493822208.21486.11348171578680982627.malonedeb@soybean.canonical.com> Message-ID: <156194935236.30949.5934340285007244779.malone@soybean.canonical.com> This issue was fixed in the openstack/neutron 14.0.2 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1824248 Title: Security Group filtering hides rules from user Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Manage Rules part of the GUI hides the rules currently visible in the Launch Instance modal window. It allows a malicious admin to add backdoor access rules that might be later added to VMs without the knowledge of owner of those VMs. When sending GET request as below, it responds only with the rules that are created by user and this happens when using Manage Rules part of the GUI: On the other hand when using GET request as below, it responds with all SG and it includes all rules, and there is no filtering and this is used in Launch Instance modal window: Here is example of rules display in Manage Rules part of GUI: > /opt/stack/horizon/openstack_dashboard/dashboards/project/security_groups/views.py(50)_get_data() -> return api.neutron.security_group_get(self.request, sg_id) (Pdb) l  45 @memoized.memoized_method  46 def _get_data(self):  47 sg_id = filters.get_int_or_uuid(self.kwargs['security_group_id'])  48 try:  49 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  50 -> return api.neutron.security_group_get(self.request, sg_id)  51 except Exception:  52 redirect = reverse('horizon:project:security_groups:index')  53 exceptions.handle(self.request,  54 _('Unable to retrieve security group.'),  55 redirect=redirect) (Pdb) p api.neutron.security_group_get(self.request, sg_id) , , , ]}> (Pdb) (Pdb) p self.request As you might have noticed there are no ports access 44 and 22 (SSH) And from the Launch Instance Modal Window, as well as CLI we can see that there are two more rules that are invisible for user, port 44 and 22 (SSH) as displayed below: > /opt/stack/horizon/openstack_dashboard/api/rest/network.py(47)get() -> return {'items': [sg.to_dict() for sg in security_groups]} (Pdb) l  42 """  43  44 security_groups = api.neutron.security_group_list(request)  45 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  46  47 -> return {'items': [sg.to_dict() for sg in security_groups]}  48  49  50 @urls.register  51 class FloatingIP(generic.View):  52 """API for a single floating IP address.""" (Pdb) p security_groups [, , , , , ]}>] (Pdb) (Pdb) p request Thank you, Robin To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1824248/+subscriptions From 1793029 at bugs.launchpad.net Wed Jul 3 14:32:20 2019 From: 1793029 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 03 Jul 2019 14:32:20 -0000 Subject: [Openstack-security] [Bug 1793029] Fix included in openstack/neutron-lib 1.28.0 References: <153722407420.8513.15403635939639716317.malonedeb@chaenomeles.canonical.com> Message-ID: <156216434063.2403.15707832812178268928.malone@soybean.canonical.com> This issue was fixed in the openstack/neutron-lib 1.28.0 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1793029 Title: adding 0.0.0.0/0 address pair to a port bypasses all other vm security groups Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: On an openstack-ansible / newton setup with linuxbridge, a customer ran: neutron port-update $port-uuid --allowed-address-pairs type=dict list=true ip_address=0.0.0.0/0 to bypass the ip source restriction (pfsense router and had to route packets). The impact of running the above, was an allow all rule was added to all ports in the network, bypassing all security groups. The iptables rule:  905K 55M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set NIPv44046d62c-59c8-4fd0-a547- src used on all ports, now triggers as: 0.0.0.0/1 128.0.0.0/1 was added to the ipset NIPv44046d62c-59c8-4fd0-a547 (verified by looking at the ipset on the nova hosts). Removing the two lines from the ipset restored all security groups. Expected result was to remove ip filtering on the single port. This sounds similar to: https://bugs.launchpad.net/neutron/+bug/1461054 but is marked fixed long ago. I've marked this as a security bug as a change to a single port can bypass other ports security groups. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1793029/+subscriptions From sean.mcginnis at gmail.com Wed Jul 3 19:56:38 2019 From: sean.mcginnis at gmail.com (Sean McGinnis) Date: Wed, 03 Jul 2019 19:56:38 -0000 Subject: [Openstack-security] [Bug 1732155] Re: bandit report: use defusedxml to avoid XML attack References: <151065694305.7350.16228969126396748741.malonedeb@soybean.canonical.com> Message-ID: <156218379904.23746.6633817339146801083.malone@chaenomeles.canonical.com> It doesn't cover everything, but at least the defusedxml.lxml module is deprecated and it has been suggested libxml has been updated enough to no longer need this. Some discussion here: https://github.com/PyCQA/bandit/issues/435 ** Changed in: cinder Status: In Progress => Invalid ** Changed in: cinder Status: Invalid => Won't Fix ** Bug watch added: github.com/PyCQA/bandit/issues #435 https://github.com/PyCQA/bandit/issues/435 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1732155 Title: bandit report: use defusedxml to avoid XML attack Status in Cinder: Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: According to https://docs.openstack.org/bandit/latest/api/bandit.blacklists.html Using various XLM methods to parse untrusted XML data is known to be vulnerable to XML attacks. Methods should be replaced with their defusedxml equivalents. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1732155/+subscriptions From 1824248 at bugs.launchpad.net Thu Jul 4 10:24:29 2019 From: 1824248 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 04 Jul 2019 10:24:29 -0000 Subject: [Openstack-security] [Bug 1824248] Fix included in openstack/neutron 12.1.0 References: <155493822208.21486.11348171578680982627.malonedeb@soybean.canonical.com> Message-ID: <156223586988.2646.3003000190827714198.malone@wampee.canonical.com> This issue was fixed in the openstack/neutron 12.1.0 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1824248 Title: Security Group filtering hides rules from user Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Manage Rules part of the GUI hides the rules currently visible in the Launch Instance modal window. It allows a malicious admin to add backdoor access rules that might be later added to VMs without the knowledge of owner of those VMs. When sending GET request as below, it responds only with the rules that are created by user and this happens when using Manage Rules part of the GUI: On the other hand when using GET request as below, it responds with all SG and it includes all rules, and there is no filtering and this is used in Launch Instance modal window: Here is example of rules display in Manage Rules part of GUI: > /opt/stack/horizon/openstack_dashboard/dashboards/project/security_groups/views.py(50)_get_data() -> return api.neutron.security_group_get(self.request, sg_id) (Pdb) l  45 @memoized.memoized_method  46 def _get_data(self):  47 sg_id = filters.get_int_or_uuid(self.kwargs['security_group_id'])  48 try:  49 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  50 -> return api.neutron.security_group_get(self.request, sg_id)  51 except Exception:  52 redirect = reverse('horizon:project:security_groups:index')  53 exceptions.handle(self.request,  54 _('Unable to retrieve security group.'),  55 redirect=redirect) (Pdb) p api.neutron.security_group_get(self.request, sg_id) , , , ]}> (Pdb) (Pdb) p self.request As you might have noticed there are no ports access 44 and 22 (SSH) And from the Launch Instance Modal Window, as well as CLI we can see that there are two more rules that are invisible for user, port 44 and 22 (SSH) as displayed below: > /opt/stack/horizon/openstack_dashboard/api/rest/network.py(47)get() -> return {'items': [sg.to_dict() for sg in security_groups]} (Pdb) l  42 """  43  44 security_groups = api.neutron.security_group_list(request)  45 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  46  47 -> return {'items': [sg.to_dict() for sg in security_groups]}  48  49  50 @urls.register  51 class FloatingIP(generic.View):  52 """API for a single floating IP address.""" (Pdb) p security_groups [, , , , , ]}>] (Pdb) (Pdb) p request Thank you, Robin To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1824248/+subscriptions From 1816836 at bugs.launchpad.net Mon Jul 22 21:30:35 2019 From: 1816836 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 22 Jul 2019 21:30:35 -0000 Subject: [Openstack-security] [Bug 1816836] Fix included in openstack/manila 6.3.1 References: <155068881794.22969.12262308667168798263.malonedeb@wampee.canonical.com> Message-ID: <156383103537.14933.11317111467069537916.malone@wampee.canonical.com> This issue was fixed in the openstack/manila 6.3.1 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1816836 Title: manila's devstack plugin fails with tls_proxy enabled Status in Manila: Fix Released Bug description: This bug was exposed in https://review.openstack.org/#/c/625191/ (Relevant log files have been attached to this bug report). Manila's devstack plugin sets the listen port to 18786 when tls_proxy has been enabled on devstack, but performs a health check on the API service on the default/non-tls port (8786) [2]. This check causes devstack to fail. [1] https://github.com/openstack/manila/blob/22d25e8/devstack/plugin.sh#L280 [2] https://github.com/openstack/manila/blob/22d25e8/devstack/plugin.sh#L830 To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1816836/+subscriptions