From 1653626 at bugs.launchpad.net Tue Jan 3 08:11:48 2017 From: 1653626 at bugs.launchpad.net (Vinita Deshpande) Date: Tue, 03 Jan 2017 08:11:48 -0000 Subject: [Openstack-security] [Bug 1653626] [NEW] IBM User tries to communicate with CoprHD securely, but fails to do so Message-ID: <20170103081148.1756.73437.malonedeb@chaenomeles.canonical.com> Public bug reported: An IBM user wanted to communicate with our backend CoprHD driver using certificate. But right now, there is not provision to do so. CoprHD should provide an option in config to perform all operations (REST API calls) using certificate verification. Both CA signed and self-signed certificates should be supported. ** Affects: cinder Importance: Undecided Assignee: Vinita Deshpande (vinita) Status: In Progress ** Tags: coprhd security ** Changed in: cinder Status: New => In Progress ** Changed in: cinder Assignee: (unassigned) => Vinita Deshpande (vinita) ** Description changed: - An IBM user wanted to communicate with our backend CoprHD driver using SSL. But right now, there is not provision to do so. CoprHD should provide an option in config to perform all operations (REST API calls) + An IBM user wanted to communicate with our backend CoprHD driver using certificate. But right now, there is not provision to do so. CoprHD should provide an option in config to perform all operations (REST API calls) using certificate verification. Both CA signed and self-signed certificates should be supported. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1653626 Title: IBM User tries to communicate with CoprHD securely, but fails to do so Status in Cinder: In Progress Bug description: An IBM user wanted to communicate with our backend CoprHD driver using certificate. But right now, there is not provision to do so. CoprHD should provide an option in config to perform all operations (REST API calls) using certificate verification. Both CA signed and self-signed certificates should be supported. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1653626/+subscriptions From 1653626 at bugs.launchpad.net Tue Jan 3 13:22:34 2017 From: 1653626 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Jan 2017 13:22:34 -0000 Subject: [Openstack-security] [Bug 1653626] Fix proposed to cinder (master) References: <20170103081148.1756.73437.malonedeb@chaenomeles.canonical.com> Message-ID: <20170103132234.1540.99202.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/416236 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1653626 Title: IBM User tries to communicate with CoprHD securely, but fails to do so Status in Cinder: In Progress Bug description: An IBM user wanted to communicate with our backend CoprHD driver using certificate. But right now, there is not provision to do so. CoprHD should provide an option in config to perform all operations (REST API calls) using certificate verification. Both CA signed and self-signed certificates should be supported. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1653626/+subscriptions From 1188189 at bugs.launchpad.net Wed Jan 11 22:10:29 2017 From: 1188189 at bugs.launchpad.net (Xing Yang) Date: Wed, 11 Jan 2017 22:10:29 -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: <20170111221029.26987.47713.malone@chaenomeles.canonical.com> In Cinder, the following drivers are using six.moves.http_client, which on python 2.7 I believe calls httplib: Location: cinder/cinder/volume/drivers/blockbridge.py:149 Location: cinder/cinder/volume/drivers/cloudbyte/cloudbyte.py:116 Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:102 Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:124 Location: cinder/cinder/volume/drivers/qnap.py:814 Location: cinder/cinder/volume/drivers/zadara.py:238 See reference of six.moves.http_client calling httplib here: https://pythonhosted.org/six/ Re-opening the bug. ** Changed in: cinder Status: Invalid => Triaged -- 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: Triaged 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 From fungi at yuggoth.org Wed Jan 11 22:53:07 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 11 Jan 2017 22:53:07 -0000 Subject: [Openstack-security] [Bug 1649446] Re: Non-Admin Access to Revocation Events References: <20161213023643.29317.10154.malonedeb@wampee.canonical.com> Message-ID: <20170111225307.21271.21705.malone@gac.canonical.com> Consensus seems to be that this was intentional behavior, but worth changing (as evidenced by a subsequent fix to master). Given that and the lack of stable branch backports, I'm going to treat this as a security hardening opportunity. If there is fierce disagreement favoring backports and an official advisory, we can revisit the classification at that time. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public Security to Public ** 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/1649446 Title: Non-Admin Access to Revocation Events Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: With the default Keystone policy any authed user can list all revocation events for the cluster: https://github.com/openstack/keystone/blob/master/etc/policy.json#L179 This can be done by directly calling the API as such: curl -g -i -X GET http://localhost/identity/v3/OS-REVOKE/events -H "Accept: application/json" -H "X-Auth-Token: " and this will provide you with a normal revocation event list (see attachment). This will allow a user to over time collect a list of user_ids and project_ids. The project_ids aren't particularly useful, but the user_ids can be used to lock people of of their accounts. Or if rate limiting is not setup (a bad idea), or somehow bypassed, would allow someone to brute force access to those ids. Knowing the ids is no worse than knowing the usernames, but as a non- admin you shouldn't have access to such a list anyway. It is also worth noting that OpenStack policy files are rife with these blank policy rules, not just Keystone. Some are safe and intended to be accessible by any authed user, others are checked at the code layer, but there may be other rules that are unsafe to expose to any authed user and as such should actually default to "rule:admin_required" or something other than blank. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1649446/+subscriptions From morgan.fainberg at gmail.com Thu Jan 12 19:16:38 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 12 Jan 2017 19:16:38 -0000 Subject: [Openstack-security] [Bug 1656076] [NEW] The keystone server auth pluigin methods could mismatch user_id in auth_context Message-ID: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> *** This bug is a security vulnerability *** Public security bug reported: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy ** Affects: keystone Importance: Undecided Status: New ** Tags: authentication security ** Tags added: authentication security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth pluigin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): New Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From morgan.fainberg at gmail.com Thu Jan 12 19:22:49 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 12 Jan 2017 19:22:49 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth pluigin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170112192249.20325.41981.malone@wampee.canonical.com> This probably should also be a lower-prio backport if possible. not a huge risk, but good to ensure we aren't in a bad state if auth methods mutate the user-id between method validation. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth pluigin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): New Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From morgan.fainberg at gmail.com Thu Jan 12 23:25:11 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 12 Jan 2017 23:25:11 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth pluigin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170112232514.13870.99851.launchpad@soybean.canonical.com> ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Medium ** Changed in: keystone Assignee: (unassigned) => Morgan Fainberg (mdrnstm) ** Also affects: keystone/newton Importance: Undecided Status: New ** Also affects: keystone/mitaka Importance: Undecided Status: New ** Also affects: keystone/ocata Importance: Medium Assignee: Morgan Fainberg (mdrnstm) Status: Triaged ** Changed in: keystone/newton Status: New => Triaged ** Changed in: keystone/newton Importance: Undecided => Medium ** Changed in: keystone/mitaka Status: New => Triaged ** Changed in: keystone/mitaka Importance: Undecided => Medium ** Changed in: keystone/mitaka Assignee: (unassigned) => Morgan Fainberg (mdrnstm) ** Changed in: keystone/newton Assignee: (unassigned) => Morgan Fainberg (mdrnstm) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth pluigin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): Triaged Status in OpenStack Identity (keystone) mitaka series: Triaged Status in OpenStack Identity (keystone) newton series: Triaged Status in OpenStack Identity (keystone) ocata series: Triaged Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Thu Jan 12 23:49:20 2017 From: 1656076 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Jan 2017 23:49:20 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth pluigin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170112234920.14419.6988.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/419693 ** Changed in: keystone Status: Triaged => In Progress ** Changed in: keystone/newton 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/1656076 Title: The keystone server auth pluigin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: In Progress Status in OpenStack Identity (keystone) newton series: In Progress Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Thu Jan 12 23:50:03 2017 From: 1656076 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Jan 2017 23:50:03 -0000 Subject: [Openstack-security] [Bug 1656076] Fix proposed to keystone (stable/newton) References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170112235003.26927.71644.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/newton Review: https://review.openstack.org/419694 ** Changed in: keystone/mitaka 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/1656076 Title: The keystone server auth pluigin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: In Progress Status in OpenStack Identity (keystone) newton series: In Progress Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Thu Jan 12 23:50:19 2017 From: 1656076 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Jan 2017 23:50:19 -0000 Subject: [Openstack-security] [Bug 1656076] Fix proposed to keystone (stable/mitaka) References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170112235019.27094.86731.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/mitaka Review: https://review.openstack.org/419695 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth pluigin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: In Progress Status in OpenStack Identity (keystone) newton series: In Progress Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From morgan.fainberg at gmail.com Fri Jan 13 01:05:47 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 13 Jan 2017 01:05:47 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth pluigin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170113010547.20557.63076.malone@wampee.canonical.com> Turns out the issue comes from the test suite not using the AuthContext object. A new patch to ensure we are using AuthContext not a dict will be proposed in lieu of the current fix. ** Changed in: keystone/mitaka Status: In Progress => Invalid ** Changed in: keystone/newton Status: In Progress => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth pluigin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From rodrigodsousa at gmail.com Fri Jan 13 02:02:33 2017 From: rodrigodsousa at gmail.com (Rodrigo Duarte) Date: Fri, 13 Jan 2017 02:02:33 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth plugin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170113020234.19945.90452.launchpad@wampee.canonical.com> ** Summary changed: - The keystone server auth pluigin methods could mismatch user_id in auth_context + The keystone server auth plugin methods could mismatch user_id in auth_context -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth plugin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Fri Jan 13 02:12:31 2017 From: 1656076 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Jan 2017 02:12:31 -0000 Subject: [Openstack-security] [Bug 1656076] Change abandoned on keystone (stable/mitaka) References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170113021231.27560.33595.malone@chaenomeles.canonical.com> Change abandoned by Morgan Fainberg (morgan.fainberg at gmail.com) on branch: stable/mitaka Review: https://review.openstack.org/419695 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth plugin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Fri Jan 13 02:12:36 2017 From: 1656076 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Jan 2017 02:12:36 -0000 Subject: [Openstack-security] [Bug 1656076] Change abandoned on keystone (stable/newton) References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170113021236.27094.28300.malone@chaenomeles.canonical.com> Change abandoned by Morgan Fainberg (morgan.fainberg at gmail.com) on branch: stable/newton Review: https://review.openstack.org/419694 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth plugin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Fri Jan 13 03:38:59 2017 From: 1656076 at bugs.launchpad.net (Steve Martinelli) Date: Fri, 13 Jan 2017 03:38:59 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth plugin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170113033902.27489.16334.launchpad@chaenomeles.canonical.com> ** Changed in: keystone/ocata Milestone: None => ocata-3 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth plugin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Fri Jan 13 17:29:33 2017 From: 1656076 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Jan 2017 17:29:33 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth plugin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170113172936.14064.31687.launchpad@soybean.canonical.com> ** Changed in: keystone Assignee: Morgan Fainberg (mdrnstm) => Steve Martinelli (stevemar) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth plugin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Fri Jan 13 17:29:53 2017 From: 1656076 at bugs.launchpad.net (Steve Martinelli) Date: Fri, 13 Jan 2017 17:29:53 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth plugin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170113172955.14534.73227.launchpad@soybean.canonical.com> ** Changed in: keystone/ocata Assignee: Steve Martinelli (stevemar) => Morgan Fainberg (mdrnstm) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth plugin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: In Progress Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From 1656076 at bugs.launchpad.net Sat Jan 14 10:35:27 2017 From: 1656076 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 14 Jan 2017 10:35:27 -0000 Subject: [Openstack-security] [Bug 1656076] Re: The keystone server auth plugin methods could mismatch user_id in auth_context References: <20170112191639.20325.60983.malonedeb@wampee.canonical.com> Message-ID: <20170114103527.20059.56811.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/419693 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=0f3f08c3df0dd6c32e685dae6726e945b01ea8c7 Submitter: Jenkins Branch: master commit 0f3f08c3df0dd6c32e685dae6726e945b01ea8c7 Author: Morgan Fainberg Date: Thu Jan 12 15:19:48 2017 -0800 Force use of AuthContext object in .authentcate() Force the keystone.auth.controllers.Auth.authenticate method to require the use of an AuthContext object instead of something duck-typed (dictionary). This is done to ensure the security and integrity of IDENTITY_KEYS are covered and values are not changed by a plugin due to the security built into AuthContext being circumvented since it was not used. This is not pythonic, this is being done for hardening purposes. Change-Id: I013846af59587d17b15ca4cf546e6372231f576e Closes-Bug: #1656076 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1656076 Title: The keystone server auth plugin methods could mismatch user_id in auth_context Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Invalid Status in OpenStack Identity (keystone) newton series: Invalid Status in OpenStack Identity (keystone) ocata series: Fix Released Bug description: The keystone server blindly overwrites the auth_context.user_id in each auth method that is run. This means that the last auth_method that is run for a given authentication request dictates the user_id. While this is not exploitable externally without misconfiguration of the external plugin methods and supporting services, this is a bad state that could relatively easily result in someone ending up authenticated with the wrong user_id. The simplest fix will be to have the for loop in the authentication controller (that iterates over the methods) to verify the user_id does not change between auth_methods executed. https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557 This has been marked as public security for hardening purposes, likely a "Class D" https://security.openstack.org/vmt-process.html#incident- report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1656076/+subscriptions From major at mhtx.net Mon Jan 16 13:58:56 2017 From: major at mhtx.net (Major Hayden) Date: Mon, 16 Jan 2017 13:58:56 -0000 Subject: [Openstack-security] [Bug 1583804] Re: Security role should require an email to receive root's mail References: <20160519213008.8116.80335.malonedeb@soybean.canonical.com> Message-ID: <20170116135856.20152.82193.malone@wampee.canonical.com> RHEL 6 STIG content is now deprecated. ** Changed in: openstack-ansible Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583804 Title: Security role should require an email to receive root's mail Status in openstack-ansible: Won't Fix Bug description: V-38680 requires that someone must receive root's email. There is not a hard requirement at the moment to set security_root_forward_email prior to running the security hardening role. There should be a pre- flight check that ensures this value is set. I'd like some more input on how we can handle this without halting the playbook run since users might not understand that this is a required configuration item. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583804/+subscriptions From major at mhtx.net Mon Jan 16 13:58:34 2017 From: major at mhtx.net (Major Hayden) Date: Mon, 16 Jan 2017 13:58:34 -0000 Subject: [Openstack-security] [Bug 1583788] Re: Security role should use pam_faillock for V-38501 on CentOS References: <20160519204832.823.4874.malonedeb@chaenomeles.canonical.com> Message-ID: <20170116135834.20965.31297.malone@gac.canonical.com> The RHEL 6 content is being deprecated and pam_faillock is used in the RHEL 7 STIG content. ** Changed in: openstack-ansible Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583788 Title: Security role should use pam_faillock for V-38501 on CentOS Status in openstack-ansible: Won't Fix Bug description: Ubuntu doesn't package pam_faillock, so fail2ban was used to satisfy the requirements in V-38501. CentOS 7 has pam_faillock and it should be used on CentOS 7 to more closely align with the STIG's requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583788/+subscriptions From major at mhtx.net Mon Jan 16 13:57:58 2017 From: major at mhtx.net (Major Hayden) Date: Mon, 16 Jan 2017 13:57:58 -0000 Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which changes require a reboot References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com> Message-ID: <20170116135801.14243.25602.launchpad@soybean.canonical.com> ** Changed in: openstack-ansible Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568070 Title: Security: Identify which changes require a reboot Status in openstack-ansible: Won't Fix Bug description: Some changes made by openstack-ansible-security require a reboot. It would be nice to alert the deployer to those changes at the end of the playbook run so they know if they had a change made that requires a reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568070/+subscriptions From major at mhtx.net Mon Jan 16 13:57:48 2017 From: major at mhtx.net (Major Hayden) Date: Mon, 16 Jan 2017 13:57:48 -0000 Subject: [Openstack-security] [Bug 1568027] Re: Security: Add docs for monitoring logs/notifications References: <20160408161603.3473.89222.malonedeb@gac.canonical.com> Message-ID: <20170116135750.27406.2140.launchpad@chaenomeles.canonical.com> ** Changed in: openstack-ansible Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568027 Title: Security: Add docs for monitoring logs/notifications Status in openstack-ansible: Won't Fix Bug description: The openstack-ansible-security docs talk about the AIDE and Auditd changes, but they don't talk much about what deployers should be doing with those notifications. Adding some friendly advice about how to handle these would be very useful. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568027/+subscriptions From major at mhtx.net Mon Jan 16 14:15:18 2017 From: major at mhtx.net (Major Hayden) Date: Mon, 16 Jan 2017 14:15:18 -0000 Subject: [Openstack-security] [Bug 1590185] Re: "V-38496 - Gather problematic system accounts" check fails on RHEL 7 References: <20160607232139.12031.65314.malonedeb@wampee.canonical.com> Message-ID: <20170116141520.20557.89161.launchpad@wampee.canonical.com> ** Changed in: openstack-ansible Status: Incomplete => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1590185 Title: "V-38496 - Gather problematic system accounts" check fails on RHEL 7 Status in openstack-ansible: Invalid Bug description: The check "V-38496 - Gather problematic system accounts" fails gloriously due to RHEL 7 not using jinja2.8 by default. The specific issue is due to Jinja being 2.7 and not 2.8. If see the following error then you need to run "pip install Jinja2 --upgrade": TASK: [openstack-ansible-security | V-38496 - Gather problematic system accounts] *** fatal: [172.31.255.20] => Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 586, in _executor exec_rc = self._executor_internal(host, new_stdin) File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 789, in _executor_internal return self._executor_internal_inner(host, self.module_name, self.module_args, inject, port, complex_args=complex_args) File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 1013, in _executor_internal_inner complex_args = template.template(self.basedir, complex_args, inject, fail_on_undefined=self.error_on_undefined_vars) File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 140, in template d[k] = template(basedir, v, templatevars, lookup_fatal, depth, expand_lists, convert_bare, fail_on_undefined, filter_fatal) File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 124, in template varname = template_from_string(basedir, varname, templatevars, fail_on_undefined) File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 382, in template_from_string res = jinja2.utils.concat(rf) File "