From colleen at gazlene.net Thu Aug 15 16:01:18 2019 From: colleen at gazlene.net (Colleen Murphy) Date: Thu, 15 Aug 2019 16:01:18 -0000 Subject: [Openstack-security] [Bug 1840288] [NEW] Trusts GET API leaks existence information to unauthorized users Message-ID: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> *** This bug is a security vulnerability *** Public security bug reported: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all- permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. ** Affects: keystone Importance: High Status: Triaged ** Tags: security trusts ** Tags removed: trus ** Tags added: security trusts -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Triaged Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From gagehugo at gmail.com Thu Aug 15 16:23:17 2019 From: gagehugo at gmail.com (Gage Hugo) Date: Thu, 15 Aug 2019 16:23:17 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156588619784.26521.5430921442854989936.malone@soybean.canonical.com> Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Incomplete Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From morgan.fainberg at gmail.com Thu Aug 15 16:33:23 2019 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 15 Aug 2019 16:33:23 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156588680385.26528.13907059183964527591.malone@gac.canonical.com> I want to note that this only impacts authenticated users. Unauthenticated users are still presented with a 403. This is probably a Class C1 [0], it requires guessing UUIDs. [0] https://security.openstack.org/vmt-process.html#incident-report- taxonomy -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Incomplete Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1840288 at bugs.launchpad.net Thu Aug 15 16:49:03 2019 From: 1840288 at bugs.launchpad.net (Guang Yee) Date: Thu, 15 Aug 2019 16:49:03 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156588774326.26528.3331887049000737629.malone@gac.canonical.com> I agree with Morgan, Class C1 sound appropriate. I think we should be able to craft a policy that authorize on trustee and trustor only. Merely changing the return code to 403 may not be the right fix. That's like security by obscurity. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Incomplete Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1840288 at bugs.launchpad.net Thu Aug 15 17:00:47 2019 From: 1840288 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 15 Aug 2019 17:00:47 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156588844951.26049.1995962037752518665.launchpad@soybean.canonical.com> ** Changed in: keystone Status: Triaged => In Progress ** Changed in: keystone Assignee: (unassigned) => Colleen Murphy (krinkle) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Incomplete Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From colleen at gazlene.net Thu Aug 15 17:02:36 2019 From: colleen at gazlene.net (Colleen Murphy) Date: Thu, 15 Aug 2019 17:02:36 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156588855652.22251.9958114674767543742.malone@chaenomeles.canonical.com> I think changing the return code is the first step, done in https://review.opendev.org/676528 (we need to change tempest too). The rest of the fix is to move all of the authorization logic into policies (https://review.opendev.org/#/q/topic:trust-policies) and then to implement system scope and default roles for the trust policies (https://launchpad.net/bugs/1818850 https://launchpad.net/bugs/1818846). -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Incomplete Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From fungi at yuggoth.org Fri Aug 16 05:29:26 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 16 Aug 2019 05:29:26 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156593336665.26244.11883990710348979092.malone@soybean.canonical.com> I concur with the class C1 suggestion here. Generally OpenStack's VMT has considered any theoretical vulnerability which depends on direct brute-forcing or guessing the UUID space as impractical, but still possibly a security hardening opportunity. ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1840288 at bugs.launchpad.net Fri Aug 16 11:34:14 2019 From: 1840288 at bugs.launchpad.net (Adam Young) Date: Fri, 16 Aug 2019 11:34:14 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> <156588855652.22251.9958114674767543742.malone@chaenomeles.canonical.com> Message-ID: This is not a bug. Trust ids are not secrets. They can and are public info. They are no more secret than a role assignment ID. Argh! On Thu, Aug 15, 2019, 1:15 PM Colleen Murphy wrote: > I think changing the return code is the first step, done in > https://review.opendev.org/676528 (we need to change tempest too). The > rest of the fix is to move all of the authorization logic into policies > (https://review.opendev.org/#/q/topic:trust-policies) and then to > implement system scope and default roles for the trust policies > (https://launchpad.net/bugs/1818850 https://launchpad.net/bugs/1818846). > > -- > You received this bug notification because you are subscribed to > OpenStack Identity (keystone). > Matching subscriptions: keystone-bugs > https://bugs.launchpad.net/bugs/1840288 > > Title: > Trusts GET API leaks existence information to unauthorized users > > Status in OpenStack Identity (keystone): > In Progress > Status in OpenStack Security Advisory: > Incomplete > > Bug description: > The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} > API leaks information about the existence of a trust to unauthorized > users. > > If an authenticated user requests a trust that either does not exist > or has no remaining uses, the returned response is a 404 regardless of > whether the user is an admin or a trustor/trustee of the hypothetical > (e.g. soft-deleted or used-up) trust. If the trust does exist but the > user has no access to it, the returned response is a 403. If an > attacker had some reasonable way of guessing or brute-forcing the UUID > of a trust, they could use this leak to confirm its existence. A valid > trust ID can then be used as part of a token request in combination > with the trustee's credentials. > > The issue is here: > > > https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 > > The current "identity:get_trust" default policy rule is "" which is > all-permissive, and authorization is hardcoded in the trust controller > code. To enforce the "only the trustor or trustee can GET this" rule, > it does a lookup of the trust and doesn't catch a NotFound, thereby > leaking it directly back to the requester. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions > -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From colleen at gazlene.net Fri Aug 16 17:25:44 2019 From: colleen at gazlene.net (Colleen Murphy) Date: Fri, 16 Aug 2019 17:25:44 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156597634464.22251.5156236635833859957.malone@chaenomeles.canonical.com> I don't see how a trust ID can be considered public information. A trust ID can be used as a component of an authentication request. It should be protected on the same level as a user ID or an application credential ID. A role ID cannot be used as part of an authentication request, knowing a role ID does not bring you any closer to getting a token. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1840288 at bugs.launchpad.net Fri Aug 16 19:07:33 2019 From: 1840288 at bugs.launchpad.net (Adam Young) Date: Fri, 16 Aug 2019 19:07:33 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156598245307.16154.14982712689989471070.malone@wampee.canonical.com> There is nothing in the trust ID itself that indicates anything about the users, the roles, or the projects in the trust. As such, they are exactly the equivalent to a role-assignment ID: You know that something exists, but you do not know anything about it. Trusts are supposed to be public in much the same way that a role assignment is public: if you know the trustor and trustee users, and the project involved, and the role, all the trust ID tells you is the pointer to the record that links that information together. It must be used in conjunction with an actual secret in order to get a token. The only information that should be considered secret is the credential used by the user to confirm their identity. This bug is invalid. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1840288 at bugs.launchpad.net Fri Aug 16 19:15:06 2019 From: 1840288 at bugs.launchpad.net (Adam Young) Date: Fri, 16 Aug 2019 19:15:06 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156598290628.23088.9154025812531945188.malone@chaenomeles.canonical.com> An App Cred ID is different in that it is more analogous to a User ID than to a Trust ID. An App Cred is more comparable to the union of the trustee user and the trust together. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1840288 at bugs.launchpad.net Fri Aug 16 19:42:33 2019 From: 1840288 at bugs.launchpad.net (Guang Yee) Date: Fri, 16 Aug 2019 19:42:33 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156598455316.26756.15809156942619199184.malone@gac.canonical.com> I think Adam's correct. Doesn't appear user can obtain a trust token if he's not a trustee. i.e. { "auth": { "identity": { "methods": [ "token" ], "token": { "id": "trustee_token" } }, "scope": { "OS-TRUST:trust": { "id": "254e874294354f7288160b6a23c174d2" } } } } If the token is not a trustee token, Keystone will reject the request with 403. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From morgan.fainberg at gmail.com Fri Aug 16 21:36:08 2019 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 16 Aug 2019 21:36:08 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156599136889.26483.14270996339662530880.malone@soybean.canonical.com> The trust could be utilized as a vector of attack, knowing the existence of a trust (and trustor/trustee) gives an additional target to utilize for social engineering and otherwise. While this is a minimal security concern overall, generally speaking information about a given grant is not available to an unknown party (within Keystone). Trusts are not intended to be public similarly they are not really intended to be privileged information. I expect this should be consistency within keystone where possible minimizing security exposure where possible. If we grant that anyone should be able to see roles that someone has on any project (provided they are logged in), I could see current behavior with trusts to be the expected behavior. This is not a critical security hole, but a chance to minimize information that can be utilized by outside (but still valid keystone users) parties not explicitly part of the delegation (Cloud Admin, Domain/Project Admin*, Trustor, Trustee) * Depending on policy configuration -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From morgan.fainberg at gmail.com Fri Aug 16 21:57:53 2019 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 16 Aug 2019 21:57:53 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156599267376.27026.6931798014148224416.malone@gac.canonical.com> Discussed in IRC[0] - conclusion is this is a Valid bug but there is no reasonable attack vector (the data could be used in determining whom to attempt to gain access to, but does not provide any means of direct attack). The data is *NOT* intended to be public but is not really explicitly private/privileged either. The API Contract and current behavior is an acceptable (as long as it is documented in this bug) behavior to leave. This may still warrant an OSSN outlining that the data is available but there is minimal or no risk. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone /%23openstack-keystone.2019-08-16.log.html#t2019-08-16T21:36:28 ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From morgan.fainberg at gmail.com Fri Aug 16 21:58:11 2019 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 16 Aug 2019 21:58:11 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156599269195.26521.1061303180725924036.malone@soybean.canonical.com> Marking as "Wont Fix" -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From colleen at gazlene.net Fri Aug 16 22:01:44 2019 From: colleen at gazlene.net (Colleen Murphy) Date: Fri, 16 Aug 2019 22:01:44 -0000 Subject: [Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156599290439.27013.1812913705570775894.malone@soybean.canonical.com> I grant that a trust ID on its own is not enough to get a token, and that moreover if someone had a trustee's credentials or intercepted token then that would already be enough to look up the trust, so the trust UUID itself is not especially sensitive information. I would not go as far as to say it is "public" information, and ideally we would make this API consistent with our other APIs by enforcing RBAC first before revealing the existence or nonexistence of a record in the database. But it is not a severe enough leak to warrant changing the API error response and so I agree with marking this Won't Fix. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1840288 at bugs.launchpad.net Fri Aug 16 22:04:14 2019 From: 1840288 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 16 Aug 2019 22:04:14 -0000 Subject: [Openstack-security] [Bug 1840288] Change abandoned on keystone (master) References: <156588487912.16463.17337117724482538969.malonedeb@wampee.canonical.com> Message-ID: <156599305418.22215.781226648531400407.malone@chaenomeles.canonical.com> Change abandoned by Colleen Murphy (colleen at gazlene.net) on branch: master Review: https://review.opendev.org/676528 Reason: As discussed in the bug report, the information leak is not severe enough to warrant changing the API behavior, so abandoning 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/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+subscriptions From 1197459 at bugs.launchpad.net Fri Aug 23 13:57:28 2019 From: 1197459 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 23 Aug 2019 13:57:28 -0000 Subject: [Openstack-security] [Bug 1197459] Related fix proposed to nova (master) References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <156656864828.2675.1447865777390414444.malone@chaenomeles.canonical.com> Related fix proposed to branch: master Review: https://review.opendev.org/678234 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From 1197459 at bugs.launchpad.net Fri Aug 23 14:11:49 2019 From: 1197459 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 23 Aug 2019 14:11:49 -0000 Subject: [Openstack-security] [Bug 1197459] Change abandoned on nova (master) References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <156656950975.3147.12769459291334720019.malone@chaenomeles.canonical.com> Change abandoned by Balazs Gibizer (balazs.gibizer at est.tech) on branch: master Review: https://review.opendev.org/678234 Reason: @Matt: thanks for the pointer. I will work on https://review.opendev.org/#/c/220622 instead. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From fungi at yuggoth.org Fri Aug 23 14:49:38 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 23 Aug 2019 14:49:38 -0000 Subject: [Openstack-security] [Bug 1841185] Re: novncproxy log contains token info References: <156656825440.32297.110137219359919545.malonedeb@soybean.canonical.com> Message-ID: <156657177808.5219.8864800619650076031.malone@wampee.canonical.com> *** This bug is a duplicate of bug 1492140 *** https://bugs.launchpad.net/bugs/1492140 I've also switched this bug to public since it's a duplicate of an already public bug. ** Information type changed from Private Security to Public ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1841185 Title: novncproxy log contains token info Status in OpenStack Compute (nova): New Bug description: Aug 23 13:07:57 ubuntu nova-novncproxy[665]: DEBUG nova.objects.console_auth_token [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] Validated token - console connection is ConsoleAuthToken(access_url_base='http://100.109.0.4:6080/vnc_lite.html',console_type='novnc',created_at=2019-08-23T13:07:03Z,host='127.0.0.1',id=1,instance_uuid=143433d6-693b-4c80-856f-ce57278a13eb,internal_access_path=None,port=5900,token='***',updated_at=None) {{(pid=8414) validate /opt/stack/nova/nova/objects/console_auth_token.py:164}} Aug 23 13:07:57 ubuntu nova-novncproxy[665]: DEBUG oslo_concurrency.lockutils [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] Acquired lock "compute-rpcapi-router" {{(pid=8414) lock /usr/local/lib/python3.6/dist-packages/oslo_concurrency/lockutils.py:265}} Aug 23 13:07:57 ubuntu nova-novncproxy[665]: DEBUG oslo_concurrency.lockutils [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] Releasing lock "compute-rpcapi-router" {{(pid=8414) lock /usr/local/lib/python3.6/dist-packages/oslo_concurrency/lockutils.py:281}} Aug 23 13:07:57 ubuntu nova-novncproxy[665]: INFO nova.console.websocketproxy [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] 8: connect info: {'token': ('534104fe-505e-48c7-afe8-64dc26043a7e',), 'instance_uuid': '143433d6-693b-4c80-856f-ce57278a13eb', 'console_type': 'novnc', 'host': '127.0.0.1', 'port': 5900, 'internal_access_path': None, 'access_url': 'http://100.109.0.4:6080/vnc_lite.html?path=%3Ftoken%3D534104fe-505e-48c7-afe8-64dc26043a7e'} The first log in the above snippet hides the token with '***' but the last log line still contains the token. The token feels like sensitive information so it should not be logged. Seen in Devstack with Nova hash 83b415041ba9ccd5b92667bfc95b6b9b003fa283 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1841185/+subscriptions From fungi at yuggoth.org Fri Aug 23 14:54:19 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 23 Aug 2019 14:54:19 -0000 Subject: [Openstack-security] [Bug 1841185] Re: novncproxy log contains token info References: <156656825440.32297.110137219359919545.malonedeb@soybean.canonical.com> Message-ID: <156657205954.2521.17417861480110129522.malone@chaenomeles.canonical.com> *** This bug is a duplicate of bug 1492140 *** https://bugs.launchpad.net/bugs/1492140 Sorry, I guess it's actually a duplicate of a public security bug, not just a normal public bug, so adjusted accordingly. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1841185 Title: novncproxy log contains token info Status in OpenStack Compute (nova): New Bug description: Aug 23 13:07:57 ubuntu nova-novncproxy[665]: DEBUG nova.objects.console_auth_token [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] Validated token - console connection is ConsoleAuthToken(access_url_base='http://100.109.0.4:6080/vnc_lite.html',console_type='novnc',created_at=2019-08-23T13:07:03Z,host='127.0.0.1',id=1,instance_uuid=143433d6-693b-4c80-856f-ce57278a13eb,internal_access_path=None,port=5900,token='***',updated_at=None) {{(pid=8414) validate /opt/stack/nova/nova/objects/console_auth_token.py:164}} Aug 23 13:07:57 ubuntu nova-novncproxy[665]: DEBUG oslo_concurrency.lockutils [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] Acquired lock "compute-rpcapi-router" {{(pid=8414) lock /usr/local/lib/python3.6/dist-packages/oslo_concurrency/lockutils.py:265}} Aug 23 13:07:57 ubuntu nova-novncproxy[665]: DEBUG oslo_concurrency.lockutils [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] Releasing lock "compute-rpcapi-router" {{(pid=8414) lock /usr/local/lib/python3.6/dist-packages/oslo_concurrency/lockutils.py:281}} Aug 23 13:07:57 ubuntu nova-novncproxy[665]: INFO nova.console.websocketproxy [None req-708425cd-0340-4d2f-a245-b19e8a381d6e None None] 8: connect info: {'token': ('534104fe-505e-48c7-afe8-64dc26043a7e',), 'instance_uuid': '143433d6-693b-4c80-856f-ce57278a13eb', 'console_type': 'novnc', 'host': '127.0.0.1', 'port': 5900, 'internal_access_path': None, 'access_url': 'http://100.109.0.4:6080/vnc_lite.html?path=%3Ftoken%3D534104fe-505e-48c7-afe8-64dc26043a7e'} The first log in the above snippet hides the token with '***' but the last log line still contains the token. The token feels like sensitive information so it should not be logged. Seen in Devstack with Nova hash 83b415041ba9ccd5b92667bfc95b6b9b003fa283 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1841185/+subscriptions From fungi at yuggoth.org Thu Aug 29 19:56:20 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 29 Aug 2019 19:56:20 -0000 Subject: [Openstack-security] [Bug 1686743] Re: Ceph credentials included in logs using older libvirt/qemu References: <20170427142747.26531.54657.malonedeb@gac.canonical.com> Message-ID: <156710858230.29344.12151957898056790177.launchpad@chaenomeles.canonical.com> ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - Older versions of libvirt included network storage authentication information on the qemu command line. If libvirt raises an exception which logs the qemu command line it used, for example an error starting a domain, this authentication information will end up in the logs. There is an existing CVE for this issue here:   https://access.redhat.com/security/cve/CVE-2015-5160 Specifically, if a deployment is using ceph, a libvirt error starting a domain would log the cephx secret key and the monitor addresses on the qemu command line. The issue has been resolved upstream. Users running qemu version 2.6 or later, and libvirt version 2.2 or later, are not vulnerable. No change is required in Nova to resolve this issue. Red Hat users running RHEL 7.3 or later are not vulnerable. It's not 100% clear to me that an OpenStack CVE is required here as it's not a bug in an OpenStack component, and it's already fixed upstream. However, it did come to my attention after a user publicly posted their ceph credentials on IRC, so evidently some OpenStack users are running vulnerable systems, and this is a very common configuration. In Nova, we currently have: MIN_LIBVIRT_VERSION = (1, 2, 9) MIN_QEMU_VERSION = (2, 1, 0) so anybody running the minimum supported versions will be vulnerable. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686743 Title: Ceph credentials included in logs using older libvirt/qemu Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Older versions of libvirt included network storage authentication information on the qemu command line. If libvirt raises an exception which logs the qemu command line it used, for example an error starting a domain, this authentication information will end up in the logs. There is an existing CVE for this issue here:   https://access.redhat.com/security/cve/CVE-2015-5160 Specifically, if a deployment is using ceph, a libvirt error starting a domain would log the cephx secret key and the monitor addresses on the qemu command line. The issue has been resolved upstream. Users running qemu version 2.6 or later, and libvirt version 2.2 or later, are not vulnerable. No change is required in Nova to resolve this issue. Red Hat users running RHEL 7.3 or later are not vulnerable. It's not 100% clear to me that an OpenStack CVE is required here as it's not a bug in an OpenStack component, and it's already fixed upstream. However, it did come to my attention after a user publicly posted their ceph credentials on IRC, so evidently some OpenStack users are running vulnerable systems, and this is a very common configuration. In Nova, we currently have: MIN_LIBVIRT_VERSION = (1, 2, 9) MIN_QEMU_VERSION = (2, 1, 0) so anybody running the minimum supported versions will be vulnerable. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1686743/+subscriptions From fungi at yuggoth.org Thu Aug 29 19:57:29 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 29 Aug 2019 19:57:29 -0000 Subject: [Openstack-security] [Bug 1546507] Re: Regular user in non-default non-recommended configuration can delete any image file References: <20160217121638.492.80062.malonedeb@gac.canonical.com> Message-ID: <156710865108.29421.6394751074390462497.launchpad@chaenomeles.canonical.com> ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - Any user can delete any public image data or get access to private image just knowing the image id. Glance allows to add custom location to image and this behavior is really harmful. Scenario of deleting image data in Ceph backend with current devstack configuration 1. User gets list of images: mfedosin at winter ~ $ glance image-list +--------------------------------------+----------------------------+ | ID | Name | +--------------------------------------+----------------------------+ | 0741cbc7-6b9f-4eb4-a666-9743a186849e | debian-8-m-agent.qcow2 | | 2e4b6dca-9700-4715-b81d-4463cd7038de | TestVM | | 39599dd3-35cb-4893-b5d4-1a17e23e538a | ubuntu14.04-x64-docker | | 153397f8-d5e5-43d1-9a08-5fc52bda11a4 | ubuntu14.04-x64-kubernetes | +--------------------------------------+----------------------------+ 2. User requests info about public image he wants to delete: mfedosin at winter ~ $ glance image-show 2e4b6dca-9700-4715-b81d-4463cd7038de +------------------+----------------------------------------------------------------------------------+ | Property | Value | +------------------+----------------------------------------------------------------------------------+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-02-11T03:38:09Z | | direct_url | rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d- | | | 4463cd7038de/snap | | disk_format | qcow2 | | id | 2e4b6dca-9700-4715-b81d-4463cd7038de | | min_disk | 0 | | min_ram | 64 | | name | TestVM | | owner | 1c6cea59a6054372b10acbab8e25e415 | | protected | False | | size | 13287936 | | status | active | | tags | [] | | updated_at | 2016-02-11T03:38:30Z | | virtual_size | None | | visibility | public | +------------------+----------------------------------------------------------------------------------+ Optional: User may try to download image file with "glance image- download 2e4b6dca-9700-4715-b81d-4463cd7038de --file gg" 3. User copies direct image url: from 'direct_url' or 'locations' field rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d-4463cd7038de/snap 4. User creates new image instance in db and sets custom location with "glance --os-image-api-version 1 image-create --location" (v1) or "glance location-add --url" (v2) mfedosin at winter ~ $ glance --os-image-api-version 1 image-create --location "rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d-4463cd7038de/snap" --disk-format qcow2 --container-format bare --name rerere +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | None | | container_format | bare | | created_at | 2016-02-17T11:54:41.000000 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | b12c6965-c6f8-4272-a8a0-453fc0fc03e2 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | rerere | | owner | fa343a042d2b47cbbeab08cca9913679 | | protected | False | | size | 13287936 | | status | active | | updated_at | 2016-02-17T11:54:44.000000 | | virtual_size | None | +------------------+--------------------------------------+ Optional: User may try to verify that image has desired location mfedosin at winter ~ $ glance image-show b12c6965-c6f8-4272-a8a0-453fc0fc03e2 +------------------+----------------------------------------------------------------------------------+ | Property | Value | +------------------+----------------------------------------------------------------------------------+ | checksum | None | | container_format | bare | | created_at | 2016-02-17T11:54:41Z | | direct_url | rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d- | | | 4463cd7038de/snap | | disk_format | qcow2 | | id | b12c6965-c6f8-4272-a8a0-453fc0fc03e2 | | min_disk | 0 | | min_ram | 0 | | name | rerere | | owner | fa343a042d2b47cbbeab08cca9913679 | | protected | False | | size | 13287936 | | status | active | | tags | [] | | updated_at | 2016-02-17T11:54:44Z | | virtual_size | None | | visibility | private | +------------------+----------------------------------------------------------------------------------+ 5. User deletes his image. Image data will be deleted too. glance image-delete b12c6965-c6f8-4272-a8a0-453fc0fc03e2 mfedosin at winter ~ $ glance image-delete b12c6965-c6f8-4272-a8a0-453fc0fc03e2 mfedosin at winter ~ $ glance image-show b12c6965-c6f8-4272-a8a0-453fc0fc03e2 404 Not Found: No image found with ID b12c6965-c6f8-4272-a8a0-453fc0fc03e2 (HTTP 404) 6. Trying to access public data will failed after that. mfedosin at winter ~ $ glance --debug image-download 2e4b6dca-9700-4715-b81d-4463cd7038de --file ggg curl -g -i -X GET -H 'Accept-Encoding: gzip, deflate' -H 'Accept: */*' -H 'User-Agent: python-glanceclient' -H 'Connection: keep-alive' -H 'X-Auth-Token: {SHA1}49eea3cf13d0aba2b76665245eab8cc45fb08342' -H 'Content-Type: application/octet-stream' http://192.168.0.2:9292/v2/images/2e4b6dca-9700-4715-b81d-4463cd7038de/file HTTP/1.1 204 No Content Date: Wed, 17 Feb 2016 12:01:54 GMT Connection: close Content-Type: text/html; charset=UTF-8 Content-Length: 0 X-Openstack-Request-Id: req-d77148fb-fd4b-4f7b-a646-30f494c480dd Traceback (most recent call last):   File "/usr/local/lib/python2.7/dist-packages/glanceclient/shell.py", line 605, in main     args.func(client, args)   File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/shell.py", line 281, in do_image_download     utils.save_image(body, args.file)   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 305, in save_image     for chunk in data:   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 478, in __iter__     self.iterable.close() AttributeError: 'NoneType' object has no attribute 'close' 'NoneType' object has no attribute 'close' mfedosin at winter ~ $ glance --version 1.2.0 Affected apis: all v1 api without any chance to fix it - v1 always allows to set custom locations. v2 api when 'show_multiple_locations' is enabled (default - False) Affected schemes: All, except 'swift+config' and 'file', because custom locations are forbidden for them. If user knows private image id he can build and set custom location to his personal image, therefore get an access to private data. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1546507 Title: Regular user in non-default non-recommended configuration can delete any image file Status in Glance: Confirmed Status in Glance liberty series: Confirmed Status in Glance mitaka series: Confirmed Status in Glance newton series: Confirmed Status in Glance ocata series: Confirmed Status in OpenStack Security Advisory: Opinion Status in OpenStack Security Notes: New Bug description: Any user can delete any public image data or get access to private image just knowing the image id. Glance allows to add custom location to image and this behavior is really harmful. Scenario of deleting image data in Ceph backend with current devstack configuration 1. User gets list of images: mfedosin at winter ~ $ glance image-list +--------------------------------------+----------------------------+ | ID | Name | +--------------------------------------+----------------------------+ | 0741cbc7-6b9f-4eb4-a666-9743a186849e | debian-8-m-agent.qcow2 | | 2e4b6dca-9700-4715-b81d-4463cd7038de | TestVM | | 39599dd3-35cb-4893-b5d4-1a17e23e538a | ubuntu14.04-x64-docker | | 153397f8-d5e5-43d1-9a08-5fc52bda11a4 | ubuntu14.04-x64-kubernetes | +--------------------------------------+----------------------------+ 2. User requests info about public image he wants to delete: mfedosin at winter ~ $ glance image-show 2e4b6dca-9700-4715-b81d-4463cd7038de +------------------+----------------------------------------------------------------------------------+ | Property | Value | +------------------+----------------------------------------------------------------------------------+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-02-11T03:38:09Z | | direct_url | rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d- | | | 4463cd7038de/snap | | disk_format | qcow2 | | id | 2e4b6dca-9700-4715-b81d-4463cd7038de | | min_disk | 0 | | min_ram | 64 | | name | TestVM | | owner | 1c6cea59a6054372b10acbab8e25e415 | | protected | False | | size | 13287936 | | status | active | | tags | [] | | updated_at | 2016-02-11T03:38:30Z | | virtual_size | None | | visibility | public | +------------------+----------------------------------------------------------------------------------+ Optional: User may try to download image file with "glance image- download 2e4b6dca-9700-4715-b81d-4463cd7038de --file gg" 3. User copies direct image url: from 'direct_url' or 'locations' field rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d-4463cd7038de/snap 4. User creates new image instance in db and sets custom location with "glance --os-image-api-version 1 image-create --location" (v1) or "glance location-add --url" (v2) mfedosin at winter ~ $ glance --os-image-api-version 1 image-create --location "rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d-4463cd7038de/snap" --disk-format qcow2 --container-format bare --name rerere +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | None | | container_format | bare | | created_at | 2016-02-17T11:54:41.000000 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | b12c6965-c6f8-4272-a8a0-453fc0fc03e2 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | rerere | | owner | fa343a042d2b47cbbeab08cca9913679 | | protected | False | | size | 13287936 | | status | active | | updated_at | 2016-02-17T11:54:44.000000 | | virtual_size | None | +------------------+--------------------------------------+ Optional: User may try to verify that image has desired location mfedosin at winter ~ $ glance image-show b12c6965-c6f8-4272-a8a0-453fc0fc03e2 +------------------+----------------------------------------------------------------------------------+ | Property | Value | +------------------+----------------------------------------------------------------------------------+ | checksum | None | | container_format | bare | | created_at | 2016-02-17T11:54:41Z | | direct_url | rbd://647f7ae8-648a-44f5-83ad-f7bd2299274e/images/2e4b6dca-9700-4715-b81d- | | | 4463cd7038de/snap | | disk_format | qcow2 | | id | b12c6965-c6f8-4272-a8a0-453fc0fc03e2 | | min_disk | 0 | | min_ram | 0 | | name | rerere | | owner | fa343a042d2b47cbbeab08cca9913679 | | protected | False | | size | 13287936 | | status | active | | tags | [] | | updated_at | 2016-02-17T11:54:44Z | | virtual_size | None | | visibility | private | +------------------+----------------------------------------------------------------------------------+ 5. User deletes his image. Image data will be deleted too. glance image-delete b12c6965-c6f8-4272-a8a0-453fc0fc03e2 mfedosin at winter ~ $ glance image-delete b12c6965-c6f8-4272-a8a0-453fc0fc03e2 mfedosin at winter ~ $ glance image-show b12c6965-c6f8-4272-a8a0-453fc0fc03e2 404 Not Found: No image found with ID b12c6965-c6f8-4272-a8a0-453fc0fc03e2 (HTTP 404) 6. Trying to access public data will failed after that. mfedosin at winter ~ $ glance --debug image-download 2e4b6dca-9700-4715-b81d-4463cd7038de --file ggg curl -g -i -X GET -H 'Accept-Encoding: gzip, deflate' -H 'Accept: */*' -H 'User-Agent: python-glanceclient' -H 'Connection: keep-alive' -H 'X-Auth-Token: {SHA1}49eea3cf13d0aba2b76665245eab8cc45fb08342' -H 'Content-Type: application/octet-stream' http://192.168.0.2:9292/v2/images/2e4b6dca-9700-4715-b81d-4463cd7038de/file HTTP/1.1 204 No Content Date: Wed, 17 Feb 2016 12:01:54 GMT Connection: close Content-Type: text/html; charset=UTF-8 Content-Length: 0 X-Openstack-Request-Id: req-d77148fb-fd4b-4f7b-a646-30f494c480dd Traceback (most recent call last):   File "/usr/local/lib/python2.7/dist-packages/glanceclient/shell.py", line 605, in main     args.func(client, args)   File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/shell.py", line 281, in do_image_download     utils.save_image(body, args.file)   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 305, in save_image     for chunk in data:   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 478, in __iter__     self.iterable.close() AttributeError: 'NoneType' object has no attribute 'close' 'NoneType' object has no attribute 'close' mfedosin at winter ~ $ glance --version 1.2.0 Affected apis: all v1 api without any chance to fix it - v1 always allows to set custom locations. v2 api when 'show_multiple_locations' is enabled (default - False) Affected schemes: All, except 'swift+config' and 'file', because custom locations are forbidden for them. If user knows private image id he can build and set custom location to his personal image, therefore get an access to private data. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1546507/+subscriptions From lbragstad at gmail.com Fri Aug 30 13:27:25 2019 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 30 Aug 2019 13:27:25 -0000 Subject: [Openstack-security] [Bug 1578466] Re: oslo.cache should offer encryption in a similar manner to keystonemiddleware cache References: <20160505031406.17572.11746.malonedeb@soybean.canonical.com> Message-ID: <156717164625.5878.18298373461126280408.launchpad@soybean.canonical.com> ** Summary changed: - cache should offer encryption in a similar manner to keystonemiddleware cache does + oslo.cache should offer encryption in a similar manner to keystonemiddleware cache ** Summary changed: - oslo.cache should offer encryption in a similar manner to keystonemiddleware cache + oslo.cache should offer encryption in a similar manner to keystonemiddleware -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1578466 Title: oslo.cache should offer encryption in a similar manner to keystonemiddleware Status in OpenStack Identity (keystone): Won't Fix Status in oslo.cache: Confirmed Bug description: Keystone middleware's caching of tokens offers HMAC validation and encryption of the tokens in the cache. This is important because memcache has literally zero authentication or protection from any user on the system. So this feature should be ported in from keystone middleware into keystone. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1578466/+subscriptions From fungi at yuggoth.org Fri Aug 30 17:34:49 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 30 Aug 2019 17:34:49 -0000 Subject: [Openstack-security] [Bug 1840895] Re: segment parameter check failed when creating network References: <156637398395.26490.15997468179982387146.malonedeb@gac.canonical.com> Message-ID: <156718649005.16492.5298639495060153710.malone@gac.canonical.com> Since there's been no objection, I'm switching this bug report to public and assessing as class D (security hardening opportunity) per the OpenStack VMT's report taxonomy: https://security.openstack.org/vmt- process.html#incident-report-taxonomy ** Information type changed from Private Security to Public ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - neutron net-create test --provider:network_type vlan --provider:segmentation_id 0 Execute commands like this, all vlan in ml2_vlan_allocations table is set to allocated, no vlan network can be created. validate_provider_segment function should check whether provider:segmentation_id is 0. ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1840895 Title: segment parameter check failed when creating network Status in neutron: Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: neutron net-create test --provider:network_type vlan --provider:segmentation_id 0 Execute commands like this, all vlan in ml2_vlan_allocations table is set to allocated, no vlan network can be created. validate_provider_segment function should check whether provider:segmentation_id is 0. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1840895/+subscriptions From 1840895 at bugs.launchpad.net Fri Aug 30 20:37:26 2019 From: 1840895 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 30 Aug 2019 20:37:26 -0000 Subject: [Openstack-security] [Bug 1840895] Re: segment parameter check failed when creating network References: <156637398395.26490.15997468179982387146.malonedeb@gac.canonical.com> Message-ID: <156719744706.977.12543531464474065149.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.opendev.org/679510 ** Changed in: neutron Status: Confirmed => 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/1840895 Title: segment parameter check failed when creating network Status in neutron: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: neutron net-create test --provider:network_type vlan --provider:segmentation_id 0 Execute commands like this, all vlan in ml2_vlan_allocations table is set to allocated, no vlan network can be created. validate_provider_segment function should check whether provider:segmentation_id is 0. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1840895/+subscriptions