From 1865840 at bugs.launchpad.net Tue Mar 3 08:17:47 2020 From: 1865840 at bugs.launchpad.net (=?utf-8?q?Rados=C5=82aw_Piliszek?=) Date: Tue, 03 Mar 2020 08:17:47 -0000 Subject: [Openstack-security] [Bug 1865840] [NEW] service-rabbitmq logs password in cleartext Message-ID: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Public bug reported: service-rabbitmq logs password in cleartext ** Affects: kolla-ansible Importance: High Assignee: Radosław Piliszek (yoctozepto) Status: In Progress ** Affects: kolla-ansible/train Importance: High Assignee: Radosław Piliszek (yoctozepto) Status: Triaged ** Affects: kolla-ansible/ussuri Importance: High Assignee: Radosław Piliszek (yoctozepto) Status: In Progress ** Tags: security ** Also affects: kolla-ansible/train Importance: Undecided Status: New ** Also affects: kolla-ansible/ussuri Importance: High Assignee: Radosław Piliszek (yoctozepto) Status: Triaged ** Changed in: kolla-ansible/train Status: New => Triaged ** Changed in: kolla-ansible/train Importance: Undecided => High ** Changed in: kolla-ansible/train Assignee: (unassigned) => Radosław Piliszek (yoctozepto) ** Changed in: kolla-ansible/train Milestone: None => 7.2.1 ** Changed in: kolla-ansible/train Milestone: 7.2.1 => 9.0.2 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: In Progress Status in kolla-ansible train series: Triaged Status in kolla-ansible ussuri series: In Progress Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From 1865840 at bugs.launchpad.net Tue Mar 3 08:25:48 2020 From: 1865840 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 08:25:48 -0000 Subject: [Openstack-security] [Bug 1865840] Re: service-rabbitmq logs password in cleartext References: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Message-ID: <158322394853.12686.2803212167618107239.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.opendev.org/710922 ** Changed in: kolla-ansible Status: Triaged => In Progress -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: In Progress Status in kolla-ansible train series: Triaged Status in kolla-ansible ussuri series: In Progress Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From mark at stackhpc.com Tue Mar 3 10:20:44 2020 From: mark at stackhpc.com (Mark Goddard) Date: Tue, 03 Mar 2020 10:20:44 -0000 Subject: [Openstack-security] [Bug 1865840] Re: service-rabbitmq logs password in cleartext References: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Message-ID: <158323084500.6414.15665910304612068436.malone@chaenomeles.canonical.com> Would be good to provide an example of leakage for reference. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: In Progress Status in kolla-ansible train series: Triaged Status in kolla-ansible ussuri series: In Progress Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From 1865840 at bugs.launchpad.net Tue Mar 3 10:32:48 2020 From: 1865840 at bugs.launchpad.net (=?utf-8?q?Rados=C5=82aw_Piliszek?=) Date: Tue, 03 Mar 2020 10:32:48 -0000 Subject: [Openstack-security] [Bug 1865840] Re: service-rabbitmq logs password in cleartext References: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Message-ID: <158323156814.11830.4515423468253200218.malone@soybean.canonical.com> Ack, special for you. Ara example output (CI): https://03319cc15cd4fcfb2a78-9347d83a8fe43a1fb2bb874d5a705361.ssl.cf5.rackcdn.com/706616/7/check /kolla-ansible-centos-source/4988719/primary/ara-report/ara-html/ (link will expire) Item { "password": "eONx3MvGdF7cuKflJ9s42GzuEQyyRCFLgTIX6Rfv", "user": "openstack", "vhost": "/" } Analogously running verbose mode. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: In Progress Status in kolla-ansible train series: Triaged Status in kolla-ansible ussuri series: In Progress Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From 1865840 at bugs.launchpad.net Tue Mar 3 10:53:55 2020 From: 1865840 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 10:53:55 -0000 Subject: [Openstack-security] [Bug 1865840] Related fix proposed to kolla-ansible (master) References: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Message-ID: <158323283520.12575.17096488501467922513.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.opendev.org/710969 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: In Progress Status in kolla-ansible train series: Triaged Status in kolla-ansible ussuri series: In Progress Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From 1865840 at bugs.launchpad.net Tue Mar 3 12:26:39 2020 From: 1865840 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 12:26:39 -0000 Subject: [Openstack-security] [Bug 1865840] Re: service-rabbitmq logs password in cleartext References: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Message-ID: <158323839961.7536.6866225081291228276.malone@chaenomeles.canonical.com> Reviewed: https://review.opendev.org/710922 Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=b1a4d8848af581388e0620d967c0ca36b000bf10 Submitter: Zuul Branch: master commit b1a4d8848af581388e0620d967c0ca36b000bf10 Author: Radosław Piliszek Date: Tue Mar 3 09:18:39 2020 +0100 service-rabbitmq: do not log password (use no_log) Change-Id: I68a40bebc174e8ebdaea36a0689b34cadb9009d2 Closes-bug: #1865840 ** Changed in: kolla-ansible Status: In Progress => Fix Released ** Changed in: kolla-ansible/train Status: Triaged => In Progress -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: Fix Released Status in kolla-ansible train series: In Progress Status in kolla-ansible ussuri series: Fix Released Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From 1865840 at bugs.launchpad.net Tue Mar 3 12:29:35 2020 From: 1865840 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 12:29:35 -0000 Subject: [Openstack-security] [Bug 1865840] Fix proposed to kolla-ansible (stable/train) References: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Message-ID: <158323857530.7488.13643198053373829067.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/train Review: https://review.opendev.org/710990 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: Fix Released Status in kolla-ansible train series: In Progress Status in kolla-ansible ussuri series: Fix Released Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From 1865840 at bugs.launchpad.net Tue Mar 3 17:33:43 2020 From: 1865840 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 17:33:43 -0000 Subject: [Openstack-security] [Bug 1865840] Re: service-rabbitmq logs password in cleartext References: <158322346711.26276.6474994292213643749.malonedeb@gac.canonical.com> Message-ID: <158325682362.11640.6929472075602993747.malone@soybean.canonical.com> Reviewed: https://review.opendev.org/710990 Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=071033fd442f1ead3dfd17ae716d0d9916290aca Submitter: Zuul Branch: stable/train commit 071033fd442f1ead3dfd17ae716d0d9916290aca Author: Radosław Piliszek Date: Tue Mar 3 09:18:39 2020 +0100 service-rabbitmq: do not log password (use no_log) Change-Id: I68a40bebc174e8ebdaea36a0689b34cadb9009d2 Closes-bug: #1865840 (cherry picked from commit b1a4d8848af581388e0620d967c0ca36b000bf10) ** Changed in: kolla-ansible/train Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865840 Title: service-rabbitmq logs password in cleartext Status in kolla-ansible: Fix Released Status in kolla-ansible train series: Fix Committed Status in kolla-ansible ussuri series: Fix Released Bug description: service-rabbitmq logs password in cleartext To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1865840/+subscriptions From 1865036 at bugs.launchpad.net Tue Mar 3 19:47:46 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 19:47:46 -0000 Subject: [Openstack-security] [Bug 1865036] Re: l3 agent metadata proxy allows access to metadata from any available network References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158326486663.26570.6008833670498402660.malone@gac.canonical.com> Reviewed: https://review.opendev.org/710458 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=5af046fd4e6387cdbf8bf65ea4c2039a4019b64b Submitter: Zuul Branch: master commit 5af046fd4e6387cdbf8bf65ea4c2039a4019b64b Author: Brian Haley Date: Thu Feb 27 17:33:28 2020 -0500 Remove extra header fields in proxied metadata requests If a user specifies a header in their request for metadata, it could override what the proxy would have inserted on their behalf. Make sure to remove any headers we don't want, and override something that might be present in the request. If the agent somehow gets a request with both headers it will silently drop it. Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6 Closes-bug: #1865036 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Tue Mar 3 20:11:20 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 20:11:20 -0000 Subject: [Openstack-security] [Bug 1865036] Fix proposed to neutron (stable/train) References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158326628086.12025.6927622251090352306.malone@wampee.canonical.com> Fix proposed to branch: stable/train Review: https://review.opendev.org/711100 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Tue Mar 3 20:11:40 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 20:11:40 -0000 Subject: [Openstack-security] [Bug 1865036] Fix proposed to neutron (stable/stein) References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158326630065.25994.15686186515785042029.malone@gac.canonical.com> Fix proposed to branch: stable/stein Review: https://review.opendev.org/711101 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Tue Mar 3 20:11:55 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 20:11:55 -0000 Subject: [Openstack-security] [Bug 1865036] Fix proposed to neutron (stable/rocky) References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158326631517.7363.4538778126825201072.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/rocky Review: https://review.opendev.org/711102 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Tue Mar 3 20:12:08 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Mar 2020 20:12:08 -0000 Subject: [Openstack-security] [Bug 1865036] Fix proposed to neutron (stable/queens) References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158326632893.11832.15133954139222969853.malone@wampee.canonical.com> Fix proposed to branch: stable/queens Review: https://review.opendev.org/711103 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Sat Mar 7 04:30:36 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 07 Mar 2020 04:30:36 -0000 Subject: [Openstack-security] [Bug 1865036] Re: l3 agent metadata proxy allows access to metadata from any available network References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158355543690.26040.6479974627119605073.malone@gac.canonical.com> Reviewed: https://review.opendev.org/711103 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b8de1e6ef01a45f75ad14d0d96cbcf40a8767f5d Submitter: Zuul Branch: stable/queens commit b8de1e6ef01a45f75ad14d0d96cbcf40a8767f5d Author: Brian Haley Date: Thu Feb 27 17:33:28 2020 -0500 Remove extra header fields in proxied metadata requests If a user specifies a header in their request for metadata, it could override what the proxy would have inserted on their behalf. Make sure to remove any headers we don't want, and override something that might be present in the request. If the agent somehow gets a request with both headers it will silently drop it. Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6 Closes-bug: #1865036 (cherry picked from commit 5af046fd4e6387cdbf8bf65ea4c2039a4019b64b) ** Tags added: in-stable-queens ** Tags added: in-stable-stein -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Sat Mar 7 04:30:46 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 07 Mar 2020 04:30:46 -0000 Subject: [Openstack-security] [Bug 1865036] Fix merged to neutron (stable/stein) References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158355544657.11880.5748391721864780316.malone@wampee.canonical.com> Reviewed: https://review.opendev.org/711101 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4dc0a61cd5aaa8a0448b19c08b9e8f04d2d11eb4 Submitter: Zuul Branch: stable/stein commit 4dc0a61cd5aaa8a0448b19c08b9e8f04d2d11eb4 Author: Brian Haley Date: Thu Feb 27 17:33:28 2020 -0500 Remove extra header fields in proxied metadata requests If a user specifies a header in their request for metadata, it could override what the proxy would have inserted on their behalf. Make sure to remove any headers we don't want, and override something that might be present in the request. If the agent somehow gets a request with both headers it will silently drop it. Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6 Closes-bug: #1865036 (cherry picked from commit 5af046fd4e6387cdbf8bf65ea4c2039a4019b64b) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Mon Mar 9 18:17:46 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 09 Mar 2020 18:17:46 -0000 Subject: [Openstack-security] [Bug 1865036] Re: l3 agent metadata proxy allows access to metadata from any available network References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158377786682.6660.10247430971682446727.malone@chaenomeles.canonical.com> Reviewed: https://review.opendev.org/711100 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bcc4f98a3d7e8f0e23cbf953cc828506a8a8002d Submitter: Zuul Branch: stable/train commit bcc4f98a3d7e8f0e23cbf953cc828506a8a8002d Author: Brian Haley Date: Thu Feb 27 17:33:28 2020 -0500 Remove extra header fields in proxied metadata requests If a user specifies a header in their request for metadata, it could override what the proxy would have inserted on their behalf. Make sure to remove any headers we don't want, and override something that might be present in the request. If the agent somehow gets a request with both headers it will silently drop it. Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6 Closes-bug: #1865036 (cherry picked from commit 5af046fd4e6387cdbf8bf65ea4c2039a4019b64b) ** Tags added: in-stable-train -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Tue Mar 10 03:15:13 2020 From: 1865036 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Mar 2020 03:15:13 -0000 Subject: [Openstack-security] [Bug 1865036] Re: l3 agent metadata proxy allows access to metadata from any available network References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158381011378.7681.12892733403791639273.malone@chaenomeles.canonical.com> Reviewed: https://review.opendev.org/711102 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1c13ad05dd937b65330c389301c2f095b7bedcd3 Submitter: Zuul Branch: stable/rocky commit 1c13ad05dd937b65330c389301c2f095b7bedcd3 Author: Brian Haley Date: Thu Feb 27 17:33:28 2020 -0500 Remove extra header fields in proxied metadata requests If a user specifies a header in their request for metadata, it could override what the proxy would have inserted on their behalf. Make sure to remove any headers we don't want, and override something that might be present in the request. If the agent somehow gets a request with both headers it will silently drop it. Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6 Closes-bug: #1865036 (cherry picked from commit 5af046fd4e6387cdbf8bf65ea4c2039a4019b64b) ** Tags added: in-stable-rocky -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From 1865036 at bugs.launchpad.net Tue Mar 10 17:45:32 2020 From: 1865036 at bugs.launchpad.net (Nick Tait) Date: Tue, 10 Mar 2020 17:45:32 -0000 Subject: [Openstack-security] [Bug 1865036] Re: l3 agent metadata proxy allows access to metadata from any available network References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158386233289.26815.3365249535105166873.malone@gac.canonical.com> I agree with C1 (or lower) classification for this. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From gagehugo at gmail.com Wed Mar 18 14:42:29 2020 From: gagehugo at gmail.com (Gage Hugo) Date: Wed, 18 Mar 2020 14:42:29 -0000 Subject: [Openstack-security] [Bug 1795800] Re: Timing oracle in core auth plugin simplifies brute-forcing usernames References: <153854884921.22301.15072922945681177517.malonedeb@gac.canonical.com> Message-ID: <158454255167.19486.5363615537487913404.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Assignee: Gage Hugo (gagehugo) => (unassigned) ** Changed in: keystone Status: In Progress => Triaged -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1795800 Title: Timing oracle in core auth plugin simplifies brute-forcing usernames Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: The response times for POST /v3/auth/tokens are significantly higher for valid usernames compared to those of invalid ones, making it possible to enumerate users on the system. Examples: # For invalid username + Request POST /v3/auth/tokens HTTP/1.1 Host: hostname:5000 Connection: close Content-Length: 141 Content-Type: application/json { "auth":{ "identity":{ "methods":[ "password" ], "password":{ "user":{ "name":"nonexisting", "domain":{ "name":"Default" }, "password":"devstacker" } } } } } + Response Time: <150ms # For valid username ('admin' in this case) + Request POST /v3/auth/tokens HTTP/1.1 Host: hostname:5000 Connection: close Content-Length: 139 Content-Type: application/json { "auth":{ "identity":{ "methods":[ "password" ], "password":{ "user":{ "name":"admin", "domain":{ "name":"Default" }, "password":"devstacker" } } } } } + Response time: >600ms # Tested version v3.8 [UPDATE 3 Oct 2018 5:01 AEST] Looks like it's also possible to enumerate for valid "domain" too. There're 2 ways that I can see: * With valid username: use the above user enum bug to guess the valid username, then brute the "domain" parameter. Response times are significantly higher for valid compared to invalid domains. * Without valid username: get a baseline response time using invalid username AND invalid domain name. Bruteforce the "domain" param until the response time hits an average high. For me invalid domain falls in the 90-100ms range whereas valid ones show 100+ms. This one looks a bit more obscure i.e. timing difference is not as distinguishable, but should still be recognizable with a good sample size. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1795800/+subscriptions From 1795800 at bugs.launchpad.net Wed Mar 18 14:43:01 2020 From: 1795800 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 18 Mar 2020 14:43:01 -0000 Subject: [Openstack-security] [Bug 1795800] Change abandoned on keystone (master) References: <153854884921.22301.15072922945681177517.malonedeb@gac.canonical.com> Message-ID: <158454258192.28071.4697416974107880385.malone@gac.canonical.com> Change abandoned by Gage Hugo (gagehugo at gmail.com) on branch: master Review: https://review.opendev.org/634826 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1795800 Title: Timing oracle in core auth plugin simplifies brute-forcing usernames Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: The response times for POST /v3/auth/tokens are significantly higher for valid usernames compared to those of invalid ones, making it possible to enumerate users on the system. Examples: # For invalid username + Request POST /v3/auth/tokens HTTP/1.1 Host: hostname:5000 Connection: close Content-Length: 141 Content-Type: application/json { "auth":{ "identity":{ "methods":[ "password" ], "password":{ "user":{ "name":"nonexisting", "domain":{ "name":"Default" }, "password":"devstacker" } } } } } + Response Time: <150ms # For valid username ('admin' in this case) + Request POST /v3/auth/tokens HTTP/1.1 Host: hostname:5000 Connection: close Content-Length: 139 Content-Type: application/json { "auth":{ "identity":{ "methods":[ "password" ], "password":{ "user":{ "name":"admin", "domain":{ "name":"Default" }, "password":"devstacker" } } } } } + Response time: >600ms # Tested version v3.8 [UPDATE 3 Oct 2018 5:01 AEST] Looks like it's also possible to enumerate for valid "domain" too. There're 2 ways that I can see: * With valid username: use the above user enum bug to guess the valid username, then brute the "domain" parameter. Response times are significantly higher for valid compared to invalid domains. * Without valid username: get a baseline response time using invalid username AND invalid domain name. Bruteforce the "domain" param until the response time hits an average high. For me invalid domain falls in the 90-100ms range whereas valid ones show 100+ms. This one looks a bit more obscure i.e. timing difference is not as distinguishable, but should still be recognizable with a good sample size. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1795800/+subscriptions From 1862050 at bugs.launchpad.net Wed Mar 18 22:18:46 2020 From: 1862050 at bugs.launchpad.net (Nick Tait) Date: Wed, 18 Mar 2020 22:18:46 -0000 Subject: [Openstack-security] [Bug 1862050] Re: Race condition while allocating floating IPs References: <158092560419.18863.6467748917645068435.malonedeb@gac.canonical.com> Message-ID: <158456992684.19341.18135441230482756062.malone@chaenomeles.canonical.com> C1 seems appropriate as the risk is not inherent to all deployments and there are multiple ways to prevent/mitigate where needed. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1862050 Title: Race condition while allocating floating IPs Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: I work as a penetration tester, in one of the last projects our team encountered a problem in openstack, We are not sure whether to consider this an openstack security vulnerability. Hope you could clarify things for us. We were testing race condition vulnerabilities on resources that have a limit per project. For example floating IP number. The idea is to make backend server recieve a lot of same requests at the same moment, and because the server has to proccess all of them simultaneously we could get a situation where the limits are not checked properly. Sending 500 requests (each in individual thread) directly to the Neutron API for allocation floating IPs resulted in exceeding the IP limit by 4 times. Request example: POST /v2.0/floatingips HTTP/1.1 Host: ... X-Auth-Token: ... Content-Type: application/json Content-Length: 103 {     "floatingip": {         "floating_network_id": "..."     } } Is it a known openstack behavior or is it more like a hardware problem? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1862050/+subscriptions From fungi at yuggoth.org Tue Mar 24 12:35:20 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 24 Mar 2020 12:35:20 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158505332125.11915.13103515579072218047.launchpad@soybean.canonical.com> ** Tags added: security ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: New Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: New Status in Manila stein series: New Status in Manila train series: New Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Tue Mar 24 15:16:18 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 Mar 2020 15:16:18 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158506297841.19284.17532728981904891947.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/train Review: https://review.opendev.org/714674 ** Changed in: manila/train Status: New => In Progress ** Changed in: manila/train Assignee: (unassigned) => Goutham Pacha Ravi (gouthamr) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: New Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: New Status in Manila stein series: New Status in Manila train series: In Progress Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Tue Mar 24 18:20:22 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 Mar 2020 18:20:22 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158507402225.19604.1822686228156123011.malone@wampee.canonical.com> Fix proposed to branch: stable/stein Review: https://review.opendev.org/714734 ** Changed in: manila/stein Status: New => In Progress ** Changed in: manila/stein Assignee: (unassigned) => Goutham Pacha Ravi (gouthamr) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: New Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: New Status in Manila stein series: In Progress Status in Manila train series: In Progress Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Tue Mar 24 19:37:03 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 Mar 2020 19:37:03 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158507862370.20119.13859536888659761986.malone@wampee.canonical.com> Reviewed: https://review.opendev.org/714674 Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=02fd716bf83849873f0bccb78b851196e6acf2b7 Submitter: Zuul Branch: stable/train commit 02fd716bf83849873f0bccb78b851196e6acf2b7 Author: Tom Barron Date: Sun Mar 1 13:12:08 2020 +0100 Enforce policy checks for share export locations Closes-bug: #1654598 Change-Id: I5f358266739f1c42343d5a0c5ec8109c8fcaac4d (cherry picked from commit 84daeb481d852d6531df11e842df1a70672d938c) ** Changed in: manila/train Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: New Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: New Status in Manila stein series: In Progress Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Wed Mar 25 16:27:46 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 Mar 2020 16:27:46 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158515366701.9037.16882279299108365006.malone@wampee.canonical.com> Reviewed: https://review.opendev.org/714734 Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=aa5e1f65cd61c57178fb864ac16bcb5c9eefb7c8 Submitter: Zuul Branch: stable/stein commit aa5e1f65cd61c57178fb864ac16bcb5c9eefb7c8 Author: Tom Barron Date: Sun Mar 1 13:12:08 2020 +0100 Enforce policy checks for share export locations Closes-bug: #1654598 Change-Id: I5f358266739f1c42343d5a0c5ec8109c8fcaac4d (cherry picked from commit 84daeb481d852d6531df11e842df1a70672d938c) (cherry picked from commit 02fd716bf83849873f0bccb78b851196e6acf2b7) ** Changed in: manila/stein Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: New Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: New Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Wed Mar 25 16:40:12 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 Mar 2020 16:40:12 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158515441221.18848.13136475316696080755.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/rocky Review: https://review.opendev.org/714993 ** Changed in: manila/rocky Status: New => In Progress ** Changed in: manila/rocky Assignee: (unassigned) => Tom Barron (tpb) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: New Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: In Progress Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From gouthampravi at gmail.com Wed Mar 25 22:53:55 2020 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Wed, 25 Mar 2020 22:53:55 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158517683794.19125.8996437594431477152.launchpad@chaenomeles.canonical.com> ** Changed in: manila/ocata Status: New => Won't Fix ** Changed in: manila/train Importance: Undecided => Low ** Changed in: manila/stein Importance: Undecided => Low ** Changed in: manila/rocky Importance: Undecided => Low ** Changed in: manila/pike Importance: Undecided => Low ** Changed in: manila/ocata Importance: Undecided => Wishlist ** Changed in: manila/queens Importance: Undecided => Low ** Tags added: in-stable-stein in-stable-train -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: In Progress Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Thu Mar 26 12:27:33 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 26 Mar 2020 12:27:33 -0000 Subject: [Openstack-security] [Bug 1654598] Fix included in openstack/manila 9.1.1 References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158522565380.7259.10003891348254525135.malone@wampee.canonical.com> This issue was fixed in the openstack/manila 9.1.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/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: In Progress Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Thu Mar 26 12:30:57 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 26 Mar 2020 12:30:57 -0000 Subject: [Openstack-security] [Bug 1654598] Fix included in openstack/manila 8.1.1 References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158522585742.10809.2143234844450826510.malone@soybean.canonical.com> This issue was fixed in the openstack/manila 8.1.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/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: In Progress Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Sun Mar 29 00:47:50 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 29 Mar 2020 00:47:50 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158544287047.12303.1346324500021601252.malone@chaenomeles.canonical.com> Reviewed: https://review.opendev.org/714993 Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=875cb87328665629778dd20951cc28e1e66d3190 Submitter: Zuul Branch: stable/rocky commit 875cb87328665629778dd20951cc28e1e66d3190 Author: Tom Barron Date: Sun Mar 1 13:12:08 2020 +0100 Enforce policy checks for share export locations Closes-bug: #1654598 Change-Id: I5f358266739f1c42343d5a0c5ec8109c8fcaac4d (cherry picked from commit 84daeb481d852d6531df11e842df1a70672d938c) (cherry picked from commit 02fd716bf83849873f0bccb78b851196e6acf2b7) (cherry picked from commit aa5e1f65cd61c57178fb864ac16bcb5c9eefb7c8) ** Changed in: manila/rocky Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: New Status in Manila queens series: New Status in Manila rocky series: Fix Committed Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Sun Mar 29 00:59:23 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 29 Mar 2020 00:59:23 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158544356389.24658.6407994066274801675.malone@soybean.canonical.com> Fix proposed to branch: stable/pike Review: https://review.opendev.org/715666 ** Changed in: manila/pike Status: New => In Progress ** Changed in: manila/pike Assignee: (unassigned) => Goutham Pacha Ravi (gouthamr) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: In Progress Status in Manila queens series: New Status in Manila rocky series: Fix Committed Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Sun Mar 29 13:08:43 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 29 Mar 2020 13:08:43 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158548732312.22286.17410271848531602744.malone@wampee.canonical.com> Fix proposed to branch: stable/queens Review: https://review.opendev.org/715687 ** Changed in: manila/queens Status: New => In Progress ** Changed in: manila/queens Assignee: (unassigned) => Tom Barron (tpb) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: In Progress Status in Manila queens series: In Progress Status in Manila rocky series: Fix Committed Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Mon Mar 30 02:03:37 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 30 Mar 2020 02:03:37 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158553381756.21168.1821726713776480525.malone@gac.canonical.com> Reviewed: https://review.opendev.org/715687 Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=d2c72aff8a38502d97e74e839866627c30ed7b31 Submitter: Zuul Branch: stable/queens commit d2c72aff8a38502d97e74e839866627c30ed7b31 Author: Tom Barron Date: Sun Mar 1 13:12:08 2020 +0100 Enforce policy checks for share export locations Closes-bug: #1654598 Change-Id: I5f358266739f1c42343d5a0c5ec8109c8fcaac4d (cherry picked from commit 84daeb481d852d6531df11e842df1a70672d938c) (cherry picked from commit 02fd716bf83849873f0bccb78b851196e6acf2b7) (cherry picked from commit aa5e1f65cd61c57178fb864ac16bcb5c9eefb7c8) (cherry picked from commit 875cb87328665629778dd20951cc28e1e66d3190) ** Changed in: manila/queens Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: In Progress Status in Manila queens series: Fix Committed Status in Manila rocky series: Fix Committed Status in Manila stein series: Fix Committed Status in Manila train series: Fix Committed Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions