From 1649634 at bugs.launchpad.net Fri Jan 5 19:07:54 2018 From: 1649634 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 05 Jan 2018 19:07:54 -0000 Subject: [Openstack-security] [Bug 1649634] Change abandoned on cinder (master) References: <20161213164942.27372.15759.malonedeb@chaenomeles.canonical.com> Message-ID: <151517927412.26715.8131380132689038058.malone@gac.canonical.com> Change abandoned by Sean McGinnis (sean.mcginnis at gmail.com) on branch: master Review: https://review.openstack.org/410874 Reason: A few months with no updates. Feel free to restore and update if you wish to continue with this. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1649634 Title: Insecure Randomness for AES Passphrase Generation Status in Cinder: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: In cinder/volume/drivers/synology/synology_common.py:176 in function _random_AES_passpharse() (sic) randint is used to generate an index that is used to select which character is added to the AES key. However, this is insecure and is stated in the Python documentation where they write "The pseudo-random generators of this module should not be used for security purposes." They recommend instead using os.urandom() or SystemRandom if a cryptographically secure prng is required. The proposed fix would be to simply be to use SystemRandom as it has all of the same functions from random implemented and does not require any new libraries. Another option is to use the Crypto library which is already imported in the file. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1649634/+subscriptions From lbragstad at gmail.com Mon Jan 8 20:41:03 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Mon, 08 Jan 2018 20:41:03 -0000 Subject: [Openstack-security] [Bug 1684320] Re: Domain admin has access to service Admin API with policy.v3cloudsample.json References: <20170419233825.2559.57296.malonedeb@wampee.canonical.com> Message-ID: <151544406332.2983.14391308223326618804.malone@soybean.canonical.com> Just to give a quick status update on the feature that will help fix this. We do have the system-scope implementation going through review now [0]. We also have a series of patches to keystone (and some other projects) that attempt to define the scope type for each policy/operation [1]. I've been tracking parts of this fix against bug 968696. [0] https://review.openstack.org/#/q/(status:merged+OR+status:open)+project:openstack/keystone+branch:master+topic:bp/system-scope [1] https://review.openstack.org/#/q/(status:merged+OR+status:open)+project:openstack/keystone+branch:master+topic:add-scope-types -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1684320 Title: Domain admin has access to service Admin API with policy.v3cloudsample.json Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: Keystone has a sample policy file to create a concept of domains per customer, with a domain admin that manages users and tenants inside that domain. https://github.com/openstack/keystone/commits/master/etc/policy.v3cloudsample.json In this policy, the domain admin role (a user who manages that domain) would get the "admin" role assigned to them. However, with the "admin" role assigned to them, they can make requests to the admin_api (in this case, the Nova example). https://github.com/openstack/nova/blob/master/nova/policies/base.py#L18-L28 I have done a fair bit of checking but I believe that a domain admin can get full access to the admin_api (or be able to create a user with an "admin" role and get access to the entire cloud). I believe this affects all other projects and users of this policy would not be aware at the level of access given to a domain admin. Perhaps the file can be revised to use a role like "domain_admin" and Keystone would have a setting of "reserved role names" which cannot be used (e.g. block the role "admin" from being created in a domain). Please forgive me in advance if this is not a security issue and a lack of understanding (I hope it is), but I have done a fair amount of research on this so far and it seems like getting access to that `admin` role is an issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1684320/+subscriptions From lbragstad at gmail.com Mon Jan 8 20:41:45 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Mon, 08 Jan 2018 20:41:45 -0000 Subject: [Openstack-security] [Bug 1684320] Re: Domain admin has access to service Admin API with policy.v3cloudsample.json References: <20170419233825.2559.57296.malonedeb@wampee.canonical.com> Message-ID: <151544410506.3376.11966542099102095803.malone@soybean.canonical.com> Do we want to track the keystone bits as duplicate of bug 968696 or should this be triaged/tracked separately? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1684320 Title: Domain admin has access to service Admin API with policy.v3cloudsample.json Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: Keystone has a sample policy file to create a concept of domains per customer, with a domain admin that manages users and tenants inside that domain. https://github.com/openstack/keystone/commits/master/etc/policy.v3cloudsample.json In this policy, the domain admin role (a user who manages that domain) would get the "admin" role assigned to them. However, with the "admin" role assigned to them, they can make requests to the admin_api (in this case, the Nova example). https://github.com/openstack/nova/blob/master/nova/policies/base.py#L18-L28 I have done a fair bit of checking but I believe that a domain admin can get full access to the admin_api (or be able to create a user with an "admin" role and get access to the entire cloud). I believe this affects all other projects and users of this policy would not be aware at the level of access given to a domain admin. Perhaps the file can be revised to use a role like "domain_admin" and Keystone would have a setting of "reserved role names" which cannot be used (e.g. block the role "admin" from being created in a domain). Please forgive me in advance if this is not a security issue and a lack of understanding (I hope it is), but I have done a fair amount of research on this so far and it seems like getting access to that `admin` role is an issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1684320/+subscriptions From fungi at yuggoth.org Mon Jan 8 20:55:33 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 08 Jan 2018 20:55:33 -0000 Subject: [Openstack-security] [Bug 1684320] Re: Domain admin has access to service Admin API with policy.v3cloudsample.json References: <20170419233825.2559.57296.malonedeb@wampee.canonical.com> Message-ID: <151544493348.26499.12389975103095687324.malone@gac.canonical.com> Seems fine to me to mark this one as a duplicate at this point. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1684320 Title: Domain admin has access to service Admin API with policy.v3cloudsample.json Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: Keystone has a sample policy file to create a concept of domains per customer, with a domain admin that manages users and tenants inside that domain. https://github.com/openstack/keystone/commits/master/etc/policy.v3cloudsample.json In this policy, the domain admin role (a user who manages that domain) would get the "admin" role assigned to them. However, with the "admin" role assigned to them, they can make requests to the admin_api (in this case, the Nova example). https://github.com/openstack/nova/blob/master/nova/policies/base.py#L18-L28 I have done a fair bit of checking but I believe that a domain admin can get full access to the admin_api (or be able to create a user with an "admin" role and get access to the entire cloud). I believe this affects all other projects and users of this policy would not be aware at the level of access given to a domain admin. Perhaps the file can be revised to use a role like "domain_admin" and Keystone would have a setting of "reserved role names" which cannot be used (e.g. block the role "admin" from being created in a domain). Please forgive me in advance if this is not a security issue and a lack of understanding (I hope it is), but I have done a fair amount of research on this so far and it seems like getting access to that `admin` role is an issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1684320/+subscriptions From fungi at yuggoth.org Mon Jan 8 20:46:59 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 08 Jan 2018 20:46:59 -0000 Subject: [Openstack-security] [Bug 1680911] Re: Revoking an unscoped token does not revoke all tokens scoped from the unscoped token References: <20170407170932.30940.87220.malonedeb@wampee.canonical.com> Message-ID: <151544441981.32264.5176861911936801818.malone@wampee.canonical.com> I don't think so, looks like we just missed lifting the embargo. Based on comments above, I'll do that now. Thanks for the reminder. ** 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. - If you create an unscoped token (A) and you then use token A to create a project-scoped token (B) you now have token (A) [audit_id] = audit_id_a token (A) [audit_chain_id] = [audit_id_a] token (B) [audit_id] = audit_id_b token (B) [audit_chain_id] = [audit_id_a, audit_id_b] If you Revoke(token A) then token B should also be invalid. However, this is not the case currently as there are two reasons for this. There is a bug that doesn't correctly catch this in revoke_models because it accidently changes a list to a list in a tuple: https://github.com/openstack/keystone/blob/master/keystone/models/revoke_model.py#L200-L201 This needs to have the comma removed from not in (token_values['audit_chain_id'],) to not in (token_values['audit_chain_id']) The second and main reason is because this functionality is never exposed to the user and in the code it is never run here: https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L255-L277 because revoke_chain=False in the parameter is never set to True in a call anywhere in the code. ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1680911 Title: Revoking an unscoped token does not revoke all tokens scoped from the unscoped token Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: If you create an unscoped token (A) and you then use token A to create a project-scoped token (B) you now have token (A) [audit_id] = audit_id_a token (A) [audit_chain_id] = [audit_id_a] token (B) [audit_id] = audit_id_b token (B) [audit_chain_id] = [audit_id_a, audit_id_b] If you Revoke(token A) then token B should also be invalid. However, this is not the case currently as there are two reasons for this. There is a bug that doesn't correctly catch this in revoke_models because it accidently changes a list to a list in a tuple: https://github.com/openstack/keystone/blob/master/keystone/models/revoke_model.py#L200-L201 This needs to have the comma removed from not in (token_values['audit_chain_id'],) to not in (token_values['audit_chain_id']) The second and main reason is because this functionality is never exposed to the user and in the code it is never run here: https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L255-L277 because revoke_chain=False in the parameter is never set to True in a call anywhere in the code. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1680911/+subscriptions From fungi at yuggoth.org Mon Jan 8 20:49:29 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 08 Jan 2018 20:49:29 -0000 Subject: [Openstack-security] [Bug 1680911] Re: Revoking an unscoped token does not revoke all tokens scoped from the unscoped token References: <20170407170932.30940.87220.malonedeb@wampee.canonical.com> Message-ID: <151544456983.26459.11762219815385142523.malone@gac.canonical.com> This report is being treated as a security hardening opportunity, class D in the OpenStack VMT report taxonomy: https://security.openstack.org /vmt-process.html#incident-report-taxonomy -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1680911 Title: Revoking an unscoped token does not revoke all tokens scoped from the unscoped token Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: If you create an unscoped token (A) and you then use token A to create a project-scoped token (B) you now have token (A) [audit_id] = audit_id_a token (A) [audit_chain_id] = [audit_id_a] token (B) [audit_id] = audit_id_b token (B) [audit_chain_id] = [audit_id_a, audit_id_b] If you Revoke(token A) then token B should also be invalid. However, this is not the case currently as there are two reasons for this. There is a bug that doesn't correctly catch this in revoke_models because it accidently changes a list to a list in a tuple: https://github.com/openstack/keystone/blob/master/keystone/models/revoke_model.py#L200-L201 This needs to have the comma removed from not in (token_values['audit_chain_id'],) to not in (token_values['audit_chain_id']) The second and main reason is because this functionality is never exposed to the user and in the code it is never run here: https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L255-L277 because revoke_chain=False in the parameter is never set to True in a call anywhere in the code. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1680911/+subscriptions From lbragstad at gmail.com Mon Jan 8 22:16:25 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Mon, 08 Jan 2018 22:16:25 -0000 Subject: [Openstack-security] [Bug 1684320] Re: Domain admin has access to service Admin API with policy.v3cloudsample.json References: <20170419233825.2559.57296.malonedeb@wampee.canonical.com> Message-ID: <151544978538.23614.7588426236543412636.malone@chaenomeles.canonical.com> *** This bug is a duplicate of bug 968696 *** https://bugs.launchpad.net/bugs/968696 Done. Thanks for the follow-up, Jeremy. ** This bug has been marked a duplicate of bug 968696 "admin"-ness not properly scoped -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1684320 Title: Domain admin has access to service Admin API with policy.v3cloudsample.json Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: Keystone has a sample policy file to create a concept of domains per customer, with a domain admin that manages users and tenants inside that domain. https://github.com/openstack/keystone/commits/master/etc/policy.v3cloudsample.json In this policy, the domain admin role (a user who manages that domain) would get the "admin" role assigned to them. However, with the "admin" role assigned to them, they can make requests to the admin_api (in this case, the Nova example). https://github.com/openstack/nova/blob/master/nova/policies/base.py#L18-L28 I have done a fair bit of checking but I believe that a domain admin can get full access to the admin_api (or be able to create a user with an "admin" role and get access to the entire cloud). I believe this affects all other projects and users of this policy would not be aware at the level of access given to a domain admin. Perhaps the file can be revised to use a role like "domain_admin" and Keystone would have a setting of "reserved role names" which cannot be used (e.g. block the role "admin" from being created in a domain). Please forgive me in advance if this is not a security issue and a lack of understanding (I hope it is), but I have done a fair amount of research on this so far and it seems like getting access to that `admin` role is an issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1684320/+subscriptions From 1534284 at bugs.launchpad.net Tue Jan 23 10:55:39 2018 From: 1534284 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 23 Jan 2018 10:55:39 -0000 Subject: [Openstack-security] [Bug 1534284] Re: keystoneauth auth plugins should not use etree XML parsing References: <20160114194930.29365.34205.malonedeb@chaenomeles.canonical.com> Message-ID: <151670493965.10677.1179488823245735281.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/536761 ** Changed in: keystoneauth Status: Triaged => In Progress ** Changed in: keystoneauth Assignee: (unassigned) => Kairat Kushaev (kkushaev) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534284 Title: keystoneauth auth plugins should not use etree XML parsing Status in keystoneauth: In Progress Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Won't Fix Bug description: XML parsing is surprisingly difficult and fraught with danger, for example entity expansion makes it easy to cause a lot of memory to be used and therefore crash your system. keystoneclient is using etree parsing which has these potential issues, although in the case of keystoneclient it's the response from the IdP which I think is generally trusted. This is in python- keystoneclient/keystoneclient/contrib/auth/v3/saml2.py There's a defusedxml parser that has protections against these attacks and should therefore be used instead if possible - https://pypi.python.org/pypi/defusedxml - the docs for this page also include some examples of other possible attacks. This was caught by bandit 0.17.0. I'm going to start this out as private security so we can think about it some more before it goes public, even though it's probably not something that needs an issue since I think the source is generally trusted. If you can't trust your IdP then who can you trust? To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534284/+subscriptions From 1188189 at bugs.launchpad.net Fri Jan 26 14:03:20 2018 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Jan 2018 14:03:20 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <151697540101.7480.5288262390312342568.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/538237 ** Changed in: cinder Status: Triaged => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in oslo.vmware: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Fix Released Status in OpenStack Object Storage (swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions