From 1174499 at bugs.launchpad.net Wed May 1 02:24:07 2013 From: 1174499 at bugs.launchpad.net (Adam Young) Date: Wed, 01 May 2013 02:24:07 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20130501022407.8669.10651.malone@wampee.canonical.com> First , Keystone needs a way to publish which hash algorithm it supports. auth_token middleware and other clients then can query this value and use it when requesting the tokens via the hash. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): Confirmed Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From thierry.carrez+lp at gmail.com Wed May 1 11:57:16 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 01 May 2013 11:57:16 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130501115716.22161.52070.malone@chaenomeles.canonical.com> @Bhuvan: care to revive your proposed patch ? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: In Progress Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From kseifried at redhat.com Wed May 1 19:43:06 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Wed, 01 May 2013 19:43:06 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20130501194306.300.46839.malone@soybean.canonical.com> One note: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=md5 Second note: based on Adam Young's comments it sounds like even the ability to forge arbitrary MD5 hashes would not be directly exploitable as 1) the MD5 hashes are created by keystone and 2) the hashed value is a PKI token so there's an additional level pf protection. Is this correct? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): Confirmed Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From 1172195 at bugs.launchpad.net Wed May 1 22:23:58 2013 From: 1172195 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 01 May 2013 22:23:58 -0000 Subject: [Openstack-security] [Bug 1172195] Fix proposed to keystone (stable/grizzly) References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com> Message-ID: <20130501222358.32061.70704.malone@gac.canonical.com> Fix proposed to branch: stable/grizzly Review: https://review.openstack.org/27980 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1172195 Title: admin_token and LDAP password show up in log in DEBUG mode Status in OpenStack Identity (Keystone): Fix Committed Bug description: This is a by-product of bug 1168252. Keystone auth_token and LDAP password are not market "secret" so they appear in DEBUG level logs: (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token = 111222333444 (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172195/+subscriptions From 1174499 at bugs.launchpad.net Thu May 2 01:06:26 2013 From: 1174499 at bugs.launchpad.net (Adam Young) Date: Thu, 02 May 2013 01:06:26 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20130502010626.8532.85276.malone@wampee.canonical.com> Kurt, those statements are correct. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): Confirmed Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From thierry.carrez+lp at gmail.com Thu May 2 12:23:22 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 02 May 2013 12:23:22 -0000 Subject: [Openstack-security] [Bug 1172195] Re: admin_token and LDAP password show up in log in DEBUG mode References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com> Message-ID: <20130502122322.22093.82408.launchpad@chaenomeles.canonical.com> ** Also affects: keystone/grizzly Importance: Undecided Status: New ** Changed in: keystone/grizzly Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1172195 Title: admin_token and LDAP password show up in log in DEBUG mode Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone grizzly series: In Progress Bug description: This is a by-product of bug 1168252. Keystone auth_token and LDAP password are not market "secret" so they appear in DEBUG level logs: (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token = 111222333444 (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172195/+subscriptions From 1172195 at bugs.launchpad.net Thu May 2 17:58:33 2013 From: 1172195 at bugs.launchpad.net (Alan Pevec) Date: Thu, 02 May 2013 17:58:33 -0000 Subject: [Openstack-security] [Bug 1172195] Re: admin_token and LDAP password show up in log in DEBUG mode References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com> Message-ID: <20130502175835.17368.12463.launchpad@wampee.canonical.com> ** Changed in: keystone/grizzly Milestone: None => 2013.1.1 ** Changed in: keystone/grizzly Assignee: (unassigned) => Adam Gandelman (gandelman-a) ** Changed in: keystone Importance: Undecided => Low ** Changed in: keystone/grizzly Importance: Undecided => Low -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1172195 Title: admin_token and LDAP password show up in log in DEBUG mode Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone grizzly series: In Progress Bug description: This is a by-product of bug 1168252. Keystone auth_token and LDAP password are not market "secret" so they appear in DEBUG level logs: (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token = 111222333444 (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172195/+subscriptions From 1172195 at bugs.launchpad.net Thu May 2 18:24:57 2013 From: 1172195 at bugs.launchpad.net (OpenStack Hudson) Date: Thu, 02 May 2013 18:24:57 -0000 Subject: [Openstack-security] [Bug 1172195] Re: admin_token and LDAP password show up in log in DEBUG mode References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com> Message-ID: <20130502182457.24740.71559.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/27980 Committed: http://github.com/openstack/keystone/commit/c5037dd6b82909efaaa8720e8cfa8bdb8b4a0edd Submitter: Jenkins Branch: stable/grizzly commit c5037dd6b82909efaaa8720e8cfa8bdb8b4a0edd Author: Xuhan Peng Date: Fri Apr 12 16:19:37 2013 +0800 Mark LDAP password and admin_token secret Add secret=True to LDAP password and admin_token of keystone configuration. Fix bug #1172195 Change-Id: I8ef7f705e3f6b374ff427c20eb761892d5146a75 (cherry picked from commit d43e2a51a1ed7adbed3c5ddf001d46bc4a824ae8) ** Changed in: keystone/grizzly Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1172195 Title: admin_token and LDAP password show up in log in DEBUG mode Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone grizzly series: Fix Committed Bug description: This is a by-product of bug 1168252. Keystone auth_token and LDAP password are not market "secret" so they appear in DEBUG level logs: (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token = 111222333444 (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172195/+subscriptions From 1172195 at bugs.launchpad.net Thu May 2 21:55:24 2013 From: 1172195 at bugs.launchpad.net (Adam Gandelman) Date: Thu, 02 May 2013 21:55:24 -0000 Subject: [Openstack-security] [Bug 1172195] Re: admin_token and LDAP password show up in log in DEBUG mode References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com> Message-ID: <20130502215524.14884.9487.launchpad@soybean.canonical.com> ** Tags removed: grizzly-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1172195 Title: admin_token and LDAP password show up in log in DEBUG mode Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone grizzly series: Fix Committed Bug description: This is a by-product of bug 1168252. Keystone auth_token and LDAP password are not market "secret" so they appear in DEBUG level logs: (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token = 111222333444 (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172195/+subscriptions From kseifried at redhat.com Mon May 6 16:46:26 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Mon, 06 May 2013 16:46:26 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20130506164626.14994.79927.malone@soybean.canonical.com> Ok treating this as security hardening, no CVE will be assigned unless new information about exploitability becomes available. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): Confirmed Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From thierry.carrez+lp at gmail.com Wed May 8 15:40:52 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 08 May 2013 15:40:52 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508154053.24841.14318.launchpad@chaenomeles.canonical.com> ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: In Progress Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1174608/+subscriptions From thierry.carrez+lp at gmail.com Wed May 8 15:50:32 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 08 May 2013 15:50:32 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508155032.14698.57687.malone@soybean.canonical.com> Will push the OSSA tomorrow -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: In Progress Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 15:43:41 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 15:43:41 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508154341.24487.34775.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/28568 ** Changed in: nova Status: Confirmed => In Progress ** Changed in: nova Assignee: (unassigned) => Russell Bryant (russellb) ** Changed in: nova/grizzly Status: New => In Progress ** Changed in: nova/grizzly Assignee: (unassigned) => Russell Bryant (russellb) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: In Progress Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 15:44:52 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 15:44:52 -0000 Subject: [Openstack-security] [Bug 1174608] Fix proposed to nova (stable/grizzly) References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508154452.15153.33735.malone@soybean.canonical.com> Fix proposed to branch: stable/grizzly Review: https://review.openstack.org/28569 ** Changed in: nova/folsom Status: New => In Progress ** Changed in: nova/folsom Assignee: (unassigned) => Russell Bryant (russellb) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: In Progress Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 15:46:36 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 15:46:36 -0000 Subject: [Openstack-security] [Bug 1174608] Fix proposed to nova (stable/folsom) References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508154636.17550.89882.malone@wampee.canonical.com> Fix proposed to branch: stable/folsom Review: https://review.openstack.org/28570 ** Changed in: python-keystoneclient Status: Confirmed => In Progress ** Changed in: python-keystoneclient Assignee: (unassigned) => Dolph Mathews (dolph) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: In Progress Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 15:50:24 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 15:50:24 -0000 Subject: [Openstack-security] [Bug 1174608] Fix proposed to python-keystoneclient (master) References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508155024.14756.67710.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/28572 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: In Progress Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 16:39:14 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 16:39:14 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508163914.14853.12903.malone@soybean.canonical.com> Fix proposed to branch: stable/folsom Review: https://review.openstack.org/28577 ** Changed in: keystone/folsom Status: New => In Progress ** Changed in: keystone/folsom Assignee: (unassigned) => Alan Pevec (apevec) ** Changed in: python-keystoneclient Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: In Progress Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 16:42:51 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 16:42:51 -0000 Subject: [Openstack-security] [Bug 1174608] Fix merged to python-keystoneclient (master) References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508164251.25081.87577.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/28572 Committed: http://github.com/openstack/python-keystoneclient/commit/1736e2ffb12f70eeebed019448bc14def48aa036 Submitter: Jenkins Branch: master commit 1736e2ffb12f70eeebed019448bc14def48aa036 Author: Dolph Mathews Date: Wed May 8 10:49:20 2013 -0500 Securely create signing_dir (bug 1174608) Also verifies the security of an existing signing_dir. Change-Id: I0685b4274a94ad3974a2b2a7ab3f45830d3934bb -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: In Progress Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 16:37:39 2013 From: 1174608 at bugs.launchpad.net (Alan Pevec) Date: Wed, 08 May 2013 16:37:39 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508163739.24913.57138.launchpad@chaenomeles.canonical.com> ** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Status: New => Invalid ** Also affects: keystone/folsom Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: In Progress Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 19:03:44 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 19:03:44 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508190344.14597.70802.malone@gac.canonical.com> Reviewed: https://review.openstack.org/28570 Committed: http://github.com/openstack/nova/commit/74aa04e2ca7942cb1e1a86dcbaffeb72d260ccd7 Submitter: Jenkins Branch: stable/folsom commit 74aa04e2ca7942cb1e1a86dcbaffeb72d260ccd7 Author: Russell Bryant Date: Wed May 1 09:41:57 2013 -0400 Remove insecure default for signing_dir option. The sample api-paste.ini file included an insecure value for the signing_dir option for the keystone authtoken middleware. Comment out the option so that we just rely on the default behavior by default. Fix bug 1174608. Conflicts: etc/nova/api-paste.ini Change-Id: I6189788953d789c34456bbe150b8ed6ce6f68403 (cherry picked from commit 58d6879b1caaa750c39c8e452a0634c24ffef2ce) ** Changed in: keystone/folsom Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Wed May 8 19:35:59 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Wed, 08 May 2013 19:35:59 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130508193559.25010.72718.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/28568 Committed: http://github.com/openstack/nova/commit/58d6879b1caaa750c39c8e452a0634c24ffef2ce Submitter: Jenkins Branch: master commit 58d6879b1caaa750c39c8e452a0634c24ffef2ce Author: Russell Bryant Date: Wed May 1 09:41:57 2013 -0400 Remove insecure default for signing_dir option. The sample api-paste.ini file included an insecure value for the signing_dir option for the keystone authtoken middleware. Comment out the option so that we just rely on the default behavior by default. Fix bug 1174608. Change-Id: I6189788953d789c34456bbe150b8ed6ce6f68403 ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: In Progress Status in OpenStack Compute (nova) grizzly series: In Progress Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1175193 at bugs.launchpad.net Wed May 8 19:26:26 2013 From: 1175193 at bugs.launchpad.net (Russell Bryant) Date: Wed, 08 May 2013 19:26:26 -0000 Subject: [Openstack-security] [Bug 1175193] Re: Instance actions history is unbounded References: <20130501143332.32195.9096.malonedeb@gac.canonical.com> Message-ID: <20130508192626.14884.99460.malone@soybean.canonical.com> Thanks for the detailed opinion, Kurt! It looks like everyone agrees that we should treat this as hardening and open this up. ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175193 Title: Instance actions history is unbounded Status in OpenStack Compute (Nova): New Bug description: Grizzly included a new feature to keep a history of actions performed on an instance. The history kept in the database is unbounded. As a result, a malicious user could perform actions in a loop and cause the database to grow without bounds. Some of the quicker actions that could be used to exploit this are pause, unpause, or change password. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1175193/+subscriptions From thierry.carrez+lp at gmail.com Thu May 9 09:03:02 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 09 May 2013 09:03:02 -0000 Subject: [Openstack-security] [Bug 1175193] Re: Instance actions history is unbounded References: <20130501143332.32195.9096.malonedeb@gac.canonical.com> Message-ID: <20130509090302.17892.57837.malone@wampee.canonical.com> Awesome, thx Kurt! I definitely agree that it's a grey area... and that if it were wildly asymmetric or unauthenticated this would be much more "exploitable". ** Changed in: nova Importance: Undecided => High ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175193 Title: Instance actions history is unbounded Status in OpenStack Compute (Nova): Confirmed Bug description: Grizzly included a new feature to keep a history of actions performed on an instance. The history kept in the database is unbounded. As a result, a malicious user could perform actions in a loop and cause the database to grow without bounds. Some of the quicker actions that could be used to exploit this are pause, unpause, or change password. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1175193/+subscriptions From thierry.carrez+lp at gmail.com Thu May 9 11:55:50 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 09 May 2013 11:55:50 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130509115554.6904.75106.launchpad@soybean.canonical.com> ** Changed in: nova/folsom Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Thu May 9 12:00:39 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Thu, 09 May 2013 12:00:39 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130509120039.17368.62762.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/28569 Committed: http://github.com/openstack/nova/commit/7bf3e8d3e254d817ff5ae7ef1f2884b10410ca60 Submitter: Jenkins Branch: stable/grizzly commit 7bf3e8d3e254d817ff5ae7ef1f2884b10410ca60 Author: Russell Bryant Date: Wed May 1 09:41:57 2013 -0400 Remove insecure default for signing_dir option. The sample api-paste.ini file included an insecure value for the signing_dir option for the keystone authtoken middleware. Comment out the option so that we just rely on the default behavior by default. Fix bug 1174608. Change-Id: I6189788953d789c34456bbe150b8ed6ce6f68403 (cherry picked from commit 58d6879b1caaa750c39c8e452a0634c24ffef2ce) ** Changed in: nova/grizzly Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From thierry.carrez+lp at gmail.com Thu May 9 13:02:40 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 09 May 2013 13:02:40 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130509130240.14756.80210.malone@gac.canonical.com> Looks like we'll have to find someone else to revive that patch. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: In Progress Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From thierry.carrez+lp at gmail.com Thu May 9 14:45:56 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 09 May 2013 14:45:56 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130509144556.24709.93051.malone@chaenomeles.canonical.com> @Pradeep: you can definitely come up with something different. reading from the original proposal it wasn't exactly perfect or approved yet. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: In Progress Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From thierry.carrez+lp at gmail.com Thu May 9 15:09:53 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 09 May 2013 15:09:53 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130509150953.15054.66609.malone@soybean.canonical.com> This does NOT affect Essex. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From thierry.carrez+lp at gmail.com Thu May 9 15:15:54 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 09 May 2013 15:15:54 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130509151554.17925.1947.malone@wampee.canonical.com> OSSA-2013-010 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1174608 at bugs.launchpad.net Thu May 9 17:54:52 2013 From: 1174608 at bugs.launchpad.net (OpenStack Hudson) Date: Thu, 09 May 2013 17:54:52 -0000 Subject: [Openstack-security] [Bug 1174608] Fix merged to keystone (stable/folsom) References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130509175452.17721.89352.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/28577 Committed: http://github.com/openstack/keystone/commit/24c25b38ed6fc95ed919ab34463cdb10bdcc57fd Submitter: Jenkins Branch: stable/folsom commit 24c25b38ed6fc95ed919ab34463cdb10bdcc57fd Author: Dolph Mathews Date: Wed May 8 10:49:20 2013 -0500 Securely create signing_dir (bug 1174608) Also verifies the security of an existing signing_dir. Change-Id: I0685b4274a94ad3974a2b2a7ab3f45830d3934bb (cherry picked from python-keystoneclient 1736e2ffb12f70eeebed019448bc14def48aa036) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From pkilambi at cisco.com Thu May 9 14:34:05 2013 From: pkilambi at cisco.com (Pradeep Kilambi) Date: Thu, 09 May 2013 14:34:05 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130509143405.14884.6753.malone@soybean.canonical.com> If no one else is working on this, I can take a look. Do we have to revive the old patch or, can i come up with some thing different. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: In Progress Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From pkilambi at cisco.com Thu May 9 14:52:47 2013 From: pkilambi at cisco.com (Pradeep Kilambi) Date: Thu, 09 May 2013 14:52:47 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130509145247.24940.39114.malone@chaenomeles.canonical.com> Thanks! I'll get started on this. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: In Progress Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From thomas at goirand.fr Thu May 9 15:07:12 2013 From: thomas at goirand.fr (Thomas Goirand) Date: Thu, 09 May 2013 15:07:12 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130509150712.14669.84750.malone@soybean.canonical.com> Hi, Is there a backport for Essex prepared by the Ubuntu security team? Or should I work on the backport myself? Thomas -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 938315 at bugs.launchpad.net Thu May 9 16:32:17 2013 From: 938315 at bugs.launchpad.net (OpenStack Hudson) Date: Thu, 09 May 2013 16:32:17 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130509163218.17519.98938.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/28686 ** Changed in: python-keystoneclient Assignee: Bhuvaneswaran A (bhuvan) => Pradeep Kilambi (pkilambi) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: In Progress Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From 938315 at bugs.launchpad.net Thu May 9 18:11:15 2013 From: 938315 at bugs.launchpad.net (OpenStack Hudson) Date: Thu, 09 May 2013 18:11:15 -0000 Subject: [Openstack-security] [Bug 938315] Fix proposed to python-keystoneclient (master) References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130509181115.17581.97901.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/28702 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: In Progress Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From 1174608 at bugs.launchpad.net Thu May 9 18:53:54 2013 From: 1174608 at bugs.launchpad.net (Alan Pevec) Date: Thu, 09 May 2013 18:53:54 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130509185356.17754.14212.launchpad@wampee.canonical.com> ** Changed in: nova/grizzly Importance: Undecided => High ** Changed in: nova/folsom Importance: Undecided => High ** Changed in: keystone/folsom Importance: Undecided => Medium ** Changed in: nova/grizzly Milestone: None => 2013.1.1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From malini.k.bhandaru at intel.com Thu May 9 23:44:35 2013 From: malini.k.bhandaru at intel.com (Bhandaru, Malini K) Date: Thu, 9 May 2013 23:44:35 +0000 Subject: [Openstack-security] keystone tokens Message-ID: Greetings!! Does anyone know why keystone design supports the creation of a fresh token for each time a user logs-in/requests a token Even if in the system there are un-expired tokens for the said user? Design justification? Apart from buggy code creating an explosion of tokens, this is a route for denial of service. Related bugs .. https://bugs.launchpad.net/keystone/+bug/1168399 https://bugs.launchpad.net/keystone/+bug/1178063 Regards Malini From 1174608 at bugs.launchpad.net Fri May 10 00:00:38 2013 From: 1174608 at bugs.launchpad.net (Alan Pevec) Date: Fri, 10 May 2013 00:00:38 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130510000042.15093.66337.launchpad@soybean.canonical.com> ** Changed in: nova/grizzly Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Released Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1172195 at bugs.launchpad.net Fri May 10 00:11:54 2013 From: 1172195 at bugs.launchpad.net (Alan Pevec) Date: Fri, 10 May 2013 00:11:54 -0000 Subject: [Openstack-security] [Bug 1172195] Re: admin_token and LDAP password show up in log in DEBUG mode References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com> Message-ID: <20130510001155.14991.72044.launchpad@gac.canonical.com> ** Changed in: keystone/grizzly Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1172195 Title: admin_token and LDAP password show up in log in DEBUG mode Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone grizzly series: Fix Released Bug description: This is a by-product of bug 1168252. Keystone auth_token and LDAP password are not market "secret" so they appear in DEBUG level logs: (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token = 111222333444 (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172195/+subscriptions From robert.clark at hp.com Fri May 10 11:22:15 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 10 May 2013 11:22:15 +0000 Subject: [Openstack-security] keystone tokens In-Reply-To: Message-ID: Does creating a new token on request invalidate the already issued (Still valid) tokens? On 10/05/2013 00:44, "Bhandaru, Malini K" wrote: >Greetings!! > >Does anyone know why keystone design supports the creation of a fresh >token for each time a user logs-in/requests a token >Even if in the system there are un-expired tokens for the said user? >Design justification? >Apart from buggy code creating an explosion of tokens, this is a route >for denial of service. >Related bugs .. > >https://bugs.launchpad.net/keystone/+bug/1168399 >https://bugs.launchpad.net/keystone/+bug/1178063 > >Regards >Malini > > > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From malini.k.bhandaru at intel.com Fri May 10 16:59:41 2013 From: malini.k.bhandaru at intel.com (Bhandaru, Malini K) Date: Fri, 10 May 2013 16:59:41 +0000 Subject: [Openstack-security] keystone tokens In-Reply-To: References: Message-ID: Adding keystone gurus ayoung and dolphm to see if they can case some light. We can have multiple valid tokens in the system for a user, valid being the operative word. They are equal citizens with respect to access rights. Regards Malini -----Original Message----- From: Clark, Robert Graham [mailto:robert.clark at hp.com] Sent: Friday, May 10, 2013 4:22 AM To: Bhandaru, Malini K; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] keystone tokens Does creating a new token on request invalidate the already issued (Still valid) tokens? On 10/05/2013 00:44, "Bhandaru, Malini K" wrote: >Greetings!! > >Does anyone know why keystone design supports the creation of a fresh >token for each time a user logs-in/requests a token Even if in the >system there are un-expired tokens for the said user? >Design justification? >Apart from buggy code creating an explosion of tokens, this is a route >for denial of service. >Related bugs .. > >https://bugs.launchpad.net/keystone/+bug/1168399 >https://bugs.launchpad.net/keystone/+bug/1178063 > >Regards >Malini > > > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From lloydostack at gmail.com Sat May 11 05:23:07 2013 From: lloydostack at gmail.com (Lloyd Dewolf) Date: Sat, 11 May 2013 05:23:07 -0000 Subject: [Openstack-security] [Bug 1168252] Re: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com> Message-ID: <20130511052307.24585.45979.malone@chaenomeles.canonical.com> For anyone else who comes along looking for the separate bug: > Thierry Carrez (ttx) wrote on 2013-04-23: > 2/ LDAP password config option is not marked "secret" so it MAY show in logs > That's what the proposed fix actually fixes. I'm not sure the LDAp password is actually logged anywhere, but marking it secret > actually makes sure it would not show if that was the case. This should be filed as a separate bug. It is #1172195 "admin_token and LDAP password show up in log in DEBUG mode" -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1168252 Title: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) Status in devstack - openstack dev environments: Confirmed Status in OpenStack Security Notes: New Status in “keystone” package in Gentoo Linux: Unknown Bug description: The password configuration of LDAP and admin_token in keystone.conf should be secret to protect security information: [ldap] # url = ldap://localhost # user = dc=Manager,dc=example,dc=com # password = None <- should be secrect # suffix = cn=example,cn=com # use_dumb_member = False # allow_subtree_delete = False # dumb_member = cn=dumb,dc=example,dc=com [DEFAULT] admin_token = passw0rd <- should be secrect To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1168252/+subscriptions From dolph.mathews at RACKSPACE.COM Fri May 10 18:58:11 2013 From: dolph.mathews at RACKSPACE.COM (Dolph Mathews) Date: Fri, 10 May 2013 18:58:11 +0000 Subject: [Openstack-security] keystone tokens In-Reply-To: References: , Message-ID: <0522D28B-3C13-4784-84DE-5B2D17002F5B@RACKSPACE.COM> Issuing a new token when a user asks for one is by design. I'm not sure that a DoS from an authenticated user is cause for concern. Suggestions: shorten token lifespan, cache your tokens client-side, flush expired tokens. -Dolph Mathews On May 10, 2013, at 12:00 PM, "Bhandaru, Malini K" wrote: > Adding keystone gurus ayoung and dolphm to see if they can case some light. > > We can have multiple valid tokens in the system for a user, valid being the operative word. > They are equal citizens with respect to access rights. > > Regards > Malini > > -----Original Message----- > From: Clark, Robert Graham [mailto:robert.clark at hp.com] > Sent: Friday, May 10, 2013 4:22 AM > To: Bhandaru, Malini K; openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] keystone tokens > > Does creating a new token on request invalidate the already issued (Still > valid) tokens? > > On 10/05/2013 00:44, "Bhandaru, Malini K" > wrote: > >> Greetings!! >> >> Does anyone know why keystone design supports the creation of a fresh >> token for each time a user logs-in/requests a token Even if in the >> system there are un-expired tokens for the said user? >> Design justification? >> Apart from buggy code creating an explosion of tokens, this is a route >> for denial of service. >> Related bugs .. >> >> https://bugs.launchpad.net/keystone/+bug/1168399 >> https://bugs.launchpad.net/keystone/+bug/1178063 >> >> Regards >> Malini >> >> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > From robert.clark at hp.com Sun May 12 18:31:25 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Sun, 12 May 2013 18:31:25 +0000 Subject: [Openstack-security] keystone tokens In-Reply-To: <0522D28B-3C13-4784-84DE-5B2D17002F5B@RACKSPACE.COM> Message-ID: Generally speaking "A DoS from an authenticated user" is a _massive_ concern for anyone who has a cloud with unaccountable users, such as shared clouds and for public clouds in particular. -Rob On 10/05/2013 19:58, "Dolph Mathews" wrote: >Issuing a new token when a user asks for one is by design. I'm not sure >that a DoS from an authenticated user is cause for concern. > >Suggestions: shorten token lifespan, cache your tokens client-side, flush >expired tokens. > >-Dolph Mathews > >On May 10, 2013, at 12:00 PM, "Bhandaru, Malini K" > wrote: > >> Adding keystone gurus ayoung and dolphm to see if they can case some >>light. >> >> We can have multiple valid tokens in the system for a user, valid being >>the operative word. >> They are equal citizens with respect to access rights. >> >> Regards >> Malini >> >> -----Original Message----- >> From: Clark, Robert Graham [mailto:robert.clark at hp.com] >> Sent: Friday, May 10, 2013 4:22 AM >> To: Bhandaru, Malini K; openstack-security at lists.openstack.org >> Subject: Re: [Openstack-security] keystone tokens >> >> Does creating a new token on request invalidate the already issued >>(Still >> valid) tokens? >> >> On 10/05/2013 00:44, "Bhandaru, Malini K" >> wrote: >> >>> Greetings!! >>> >>> Does anyone know why keystone design supports the creation of a fresh >>> token for each time a user logs-in/requests a token Even if in the >>> system there are un-expired tokens for the said user? >>> Design justification? >>> Apart from buggy code creating an explosion of tokens, this is a route >>> for denial of service. >>> Related bugs .. >>> >>> https://bugs.launchpad.net/keystone/+bug/1168399 >>> https://bugs.launchpad.net/keystone/+bug/1178063 >>> >>> Regards >>> Malini >>> >>> >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> From thierry.carrez+lp at gmail.com Mon May 13 07:18:45 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 13 May 2013 07:18:45 -0000 Subject: [Openstack-security] [Bug 1168252] Re: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com> Message-ID: <20130513071846.25630.77032.launchpad@chaenomeles.canonical.com> ** CVE removed: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2006 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1168252 Title: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) Status in devstack - openstack dev environments: Confirmed Status in OpenStack Security Notes: New Status in “keystone” package in Gentoo Linux: Unknown Bug description: The password configuration of LDAP and admin_token in keystone.conf should be secret to protect security information: [ldap] # url = ldap://localhost # user = dc=Manager,dc=example,dc=com # password = None <- should be secrect # suffix = cn=example,cn=com # use_dumb_member = False # allow_subtree_delete = False # dumb_member = cn=dumb,dc=example,dc=com [DEFAULT] admin_token = passw0rd <- should be secrect To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1168252/+subscriptions From thierry.carrez+lp at gmail.com Mon May 13 12:43:46 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 13 May 2013 12:43:46 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20130513124346.30730.27734.launchpad@soybean.canonical.com> ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): New Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From thierry.carrez+lp at gmail.com Mon May 13 12:44:06 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 13 May 2013 12:44:06 -0000 Subject: [Openstack-security] [Bug 1175904] Re: passlib trunc_password MAX_PASSWORD_LENGTH password truncation References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20130513124407.392.54142.launchpad@wampee.canonical.com> ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): New Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From simo at redhat.com Mon May 13 13:11:26 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 13 May 2013 09:11:26 -0400 Subject: [Openstack-security] keystone tokens In-Reply-To: References: Message-ID: <1368450686.20220.204.camel@willson.li.ssimo.org> On Sun, 2013-05-12 at 18:31 +0000, Clark, Robert Graham wrote: > Generally speaking "A DoS from an authenticated user" is a _massive_ > concern for anyone who has a cloud with unaccountable users, such as > shared clouds and for public clouds in particular. Authenticated users usually have many many ways to cause excessive use of resources. If you are concerned about an authenticated user causing DoS I think the right answer is to look at rate limiting and a monitoring system that reports which users are abusing the system. It's easy to (auto?)terminate accounts that are misbehaving. A completely different class than anonymous DoS. simo. -- Simo Sorce * Red Hat, Inc * New York From thierry.carrez+lp at gmail.com Wed May 15 12:19:34 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 15 May 2013 12:19:34 -0000 Subject: [Openstack-security] [Bug 1178032] Re: ldap list members returns passwords References: <20130509001314.14958.69418.malonedeb@gac.canonical.com> Message-ID: <20130515121935.573.22821.launchpad@soybean.canonical.com> ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1178032 Title: ldap list members returns passwords Status in OpenStack Identity (Keystone): Confirmed Bug description: If I'm using the LDAP identity backend, listing group users includes the users' passwords (sha-encoded, but that probably depends on LDAP server configuration). Keystone shouldn't be handing out users' passwords. The fix is probably to just remove the password attribute. If Keystone is just returning all attributes, then it should be changed to only return the attributes that are known to be safe. Steps to recreate: 1) start with devstack configured to use LDAP # set LDAP options in localrc ./stack.sh ... 2) add the default domain since it doesn't exist by default for some reason. $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: cn=default,ou=Domains,dc=openstack,dc=org objectclass: groupOfNames member: cn=dummy 3) Create a couple users (set environment variables so you're admin) $ keystone user-create --name user1 --pass user1pwd (example id is 1db4a4d16ba1458aae139db0f43b0904) $ keystone user-create --name user2 --pass user2pwd (example id is 4091d11924f5498c8008b655bcf94b9d) 4) Create a group $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: ou=UserGroups,dc=openstack,dc=org objectclass: organizationalUnit dn: cn=group1,ou=UserGroups,dc=openstack,dc=org objectclass: groupOfNames member: cn=1db4a4d16ba1458aae139db0f43b0904,ou=Users,dc=openstack,dc=org member: cn=4091d11924f5498c8008b655bcf94b9d,ou=Users,dc=openstack,dc=org 5) List the group members: $ curl -H "X-Auth-Token: admintoken" http://localhost:35357/v3/groups/group1/users | python -m json.tool { "links": { "next": null, "previous": null, "self": "http://localhost:5000/v3/groups/group1/users" }, "users": [ { "domain_id": "default", "id": "1db4a4d16ba1458aae139db0f43b0904", "links": { "self": "http://localhost:5000/v3/users/1db4a4d16ba1458aae139db0f43b0904" }, "name": "user1", "password": "{SSHA}eQnQSd6SS6tioL/uN4M7odr/cf2SsjbG" }, { "domain_id": "default", "id": "4091d11924f5498c8008b655bcf94b9d", "links": { "self": "http://localhost:5000/v3/users/4091d11924f5498c8008b655bcf94b9d" }, "name": "user2", "password": "{SSHA}HDtgM7HcrlXnLM7N85htpz1kKYL2npMS" } ] } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1178032/+subscriptions From bdpayne at acm.org Wed May 15 15:49:25 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 15 May 2013 15:49:25 -0000 Subject: [Openstack-security] [Bug 1178032] Re: ldap list members returns passwords References: <20130509001314.14958.69418.malonedeb@gac.canonical.com> Message-ID: <20130515154925.7021.75684.malone@wampee.canonical.com> In all of the examples above, the admin is grabbing the passwords over HTTP... so anyone on that network can see them. Perhaps this is an orthogonal issue. But I think that it goes towards how bad it is to be moving SHA-1 password hashes around in the system. There will be unintended consequences because admins won't expect this behavior and/or won't understand how to properly protect themselves. A good policy here should be to not deliver SHA-1 password hashes by default *ever*. And then to only make it an option for properly privileged users if there is a valid use case for why they would need them. At the moment, I'm not seeing that use case here. It seems to me that the connection to the LDAP server should be setup to not send this information back to Keystone, if at all possible. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1178032 Title: ldap list members returns passwords Status in OpenStack Identity (Keystone): Confirmed Bug description: If I'm using the LDAP identity backend, listing group users includes the users' passwords (sha-encoded, but that probably depends on LDAP server configuration). Keystone shouldn't be handing out users' passwords. The fix is probably to just remove the password attribute. If Keystone is just returning all attributes, then it should be changed to only return the attributes that are known to be safe. Steps to recreate: 1) start with devstack configured to use LDAP # set LDAP options in localrc ./stack.sh ... 2) add the default domain since it doesn't exist by default for some reason. $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: cn=default,ou=Domains,dc=openstack,dc=org objectclass: groupOfNames member: cn=dummy 3) Create a couple users (set environment variables so you're admin) $ keystone user-create --name user1 --pass user1pwd (example id is 1db4a4d16ba1458aae139db0f43b0904) $ keystone user-create --name user2 --pass user2pwd (example id is 4091d11924f5498c8008b655bcf94b9d) 4) Create a group $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: ou=UserGroups,dc=openstack,dc=org objectclass: organizationalUnit dn: cn=group1,ou=UserGroups,dc=openstack,dc=org objectclass: groupOfNames member: cn=1db4a4d16ba1458aae139db0f43b0904,ou=Users,dc=openstack,dc=org member: cn=4091d11924f5498c8008b655bcf94b9d,ou=Users,dc=openstack,dc=org 5) List the group members: $ curl -H "X-Auth-Token: admintoken" http://localhost:35357/v3/groups/group1/users | python -m json.tool { "links": { "next": null, "previous": null, "self": "http://localhost:5000/v3/groups/group1/users" }, "users": [ { "domain_id": "default", "id": "1db4a4d16ba1458aae139db0f43b0904", "links": { "self": "http://localhost:5000/v3/users/1db4a4d16ba1458aae139db0f43b0904" }, "name": "user1", "password": "{SSHA}eQnQSd6SS6tioL/uN4M7odr/cf2SsjbG" }, { "domain_id": "default", "id": "4091d11924f5498c8008b655bcf94b9d", "links": { "self": "http://localhost:5000/v3/users/4091d11924f5498c8008b655bcf94b9d" }, "name": "user2", "password": "{SSHA}HDtgM7HcrlXnLM7N85htpz1kKYL2npMS" } ] } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1178032/+subscriptions From 1178032 at bugs.launchpad.net Wed May 15 15:40:55 2013 From: 1178032 at bugs.launchpad.net (Adam Young) Date: Wed, 15 May 2013 15:40:55 -0000 Subject: [Openstack-security] [Bug 1178032] Re: ldap list members returns passwords References: <20130509001314.14958.69418.malonedeb@gac.canonical.com> Message-ID: <20130515154056.20259.6659.launchpad@gac.canonical.com> ** Changed in: keystone Assignee: (unassigned) => Adam Young (ayoung) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1178032 Title: ldap list members returns passwords Status in OpenStack Identity (Keystone): Confirmed Bug description: If I'm using the LDAP identity backend, listing group users includes the users' passwords (sha-encoded, but that probably depends on LDAP server configuration). Keystone shouldn't be handing out users' passwords. The fix is probably to just remove the password attribute. If Keystone is just returning all attributes, then it should be changed to only return the attributes that are known to be safe. Steps to recreate: 1) start with devstack configured to use LDAP # set LDAP options in localrc ./stack.sh ... 2) add the default domain since it doesn't exist by default for some reason. $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: cn=default,ou=Domains,dc=openstack,dc=org objectclass: groupOfNames member: cn=dummy 3) Create a couple users (set environment variables so you're admin) $ keystone user-create --name user1 --pass user1pwd (example id is 1db4a4d16ba1458aae139db0f43b0904) $ keystone user-create --name user2 --pass user2pwd (example id is 4091d11924f5498c8008b655bcf94b9d) 4) Create a group $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: ou=UserGroups,dc=openstack,dc=org objectclass: organizationalUnit dn: cn=group1,ou=UserGroups,dc=openstack,dc=org objectclass: groupOfNames member: cn=1db4a4d16ba1458aae139db0f43b0904,ou=Users,dc=openstack,dc=org member: cn=4091d11924f5498c8008b655bcf94b9d,ou=Users,dc=openstack,dc=org 5) List the group members: $ curl -H "X-Auth-Token: admintoken" http://localhost:35357/v3/groups/group1/users | python -m json.tool { "links": { "next": null, "previous": null, "self": "http://localhost:5000/v3/groups/group1/users" }, "users": [ { "domain_id": "default", "id": "1db4a4d16ba1458aae139db0f43b0904", "links": { "self": "http://localhost:5000/v3/users/1db4a4d16ba1458aae139db0f43b0904" }, "name": "user1", "password": "{SSHA}eQnQSd6SS6tioL/uN4M7odr/cf2SsjbG" }, { "domain_id": "default", "id": "4091d11924f5498c8008b655bcf94b9d", "links": { "self": "http://localhost:5000/v3/users/4091d11924f5498c8008b655bcf94b9d" }, "name": "user2", "password": "{SSHA}HDtgM7HcrlXnLM7N85htpz1kKYL2npMS" } ] } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1178032/+subscriptions From 1178032 at bugs.launchpad.net Thu May 16 13:22:04 2013 From: 1178032 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 16 May 2013 13:22:04 -0000 Subject: [Openstack-security] [Bug 1178032] Re: ldap driver returns hashed passwords References: <20130509001314.14958.69418.malonedeb@gac.canonical.com> Message-ID: <20130516132204.7389.55462.launchpad@wampee.canonical.com> ** Summary changed: - ldap list members returns passwords + ldap driver returns hashed passwords -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1178032 Title: ldap driver returns hashed passwords Status in OpenStack Identity (Keystone): Confirmed Bug description: If I'm using the LDAP identity backend, listing group users includes the users' passwords (sha-encoded, but that probably depends on LDAP server configuration). Keystone shouldn't be handing out users' passwords. The fix is probably to just remove the password attribute. If Keystone is just returning all attributes, then it should be changed to only return the attributes that are known to be safe. Steps to recreate: 1) start with devstack configured to use LDAP # set LDAP options in localrc ./stack.sh ... 2) add the default domain since it doesn't exist by default for some reason. $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: cn=default,ou=Domains,dc=openstack,dc=org objectclass: groupOfNames member: cn=dummy 3) Create a couple users (set environment variables so you're admin) $ keystone user-create --name user1 --pass user1pwd (example id is 1db4a4d16ba1458aae139db0f43b0904) $ keystone user-create --name user2 --pass user2pwd (example id is 4091d11924f5498c8008b655bcf94b9d) 4) Create a group $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd dn: ou=UserGroups,dc=openstack,dc=org objectclass: organizationalUnit dn: cn=group1,ou=UserGroups,dc=openstack,dc=org objectclass: groupOfNames member: cn=1db4a4d16ba1458aae139db0f43b0904,ou=Users,dc=openstack,dc=org member: cn=4091d11924f5498c8008b655bcf94b9d,ou=Users,dc=openstack,dc=org 5) List the group members: $ curl -H "X-Auth-Token: admintoken" http://localhost:35357/v3/groups/group1/users | python -m json.tool { "links": { "next": null, "previous": null, "self": "http://localhost:5000/v3/groups/group1/users" }, "users": [ { "domain_id": "default", "id": "1db4a4d16ba1458aae139db0f43b0904", "links": { "self": "http://localhost:5000/v3/users/1db4a4d16ba1458aae139db0f43b0904" }, "name": "user1", "password": "{SSHA}eQnQSd6SS6tioL/uN4M7odr/cf2SsjbG" }, { "domain_id": "default", "id": "4091d11924f5498c8008b655bcf94b9d", "links": { "self": "http://localhost:5000/v3/users/4091d11924f5498c8008b655bcf94b9d" }, "name": "user2", "password": "{SSHA}HDtgM7HcrlXnLM7N85htpz1kKYL2npMS" } ] } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1178032/+subscriptions From thierry.carrez+lp at gmail.com Fri May 17 07:51:57 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 17 May 2013 07:51:57 -0000 Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords trigger long checks References: <20130503065128.15095.65477.malonedeb@gac.canonical.com> Message-ID: <20130517075157.7428.53026.malone@wampee.canonical.com> Opening so that we can apply the strengthening in a public patch. ** Summary changed: - passlib long password DoS + passlib: long passwords trigger long checks ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175906 Title: passlib: long passwords trigger long checks Status in OpenStack Identity (Keystone): New Bug description: Grant Murphy originally reported: * Denial of Service The passlib restriction of 4096 for maximum password length is potentially too generous for production environments. On my local machine the sha512_crypt algorithm with input of 4096 and 40000 rounds will potentially introduce a DOS problem: feasible length(128) password encrypt: 0.0707409381866 seconds feasible length(128) password verify: 0.140727996826 seconds excessive length(4096) password encrypt: 1.33277702332 seconds excessive length(4096) password verify: 2.66491699219 seconds I would consider tweaking these values (length or rounds) to reduce the computational overhead here or you're probably going to have a bad time. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175906/+subscriptions From ssorce at redhat.com Fri May 17 08:55:38 2013 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 17 May 2013 04:55:38 -0400 (EDT) Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords trigger long checks In-Reply-To: <20130517075157.7428.53026.malone@wampee.canonical.com> References: <20130503065128.15095.65477.malonedeb@gac.canonical.com> <20130517075157.7428.53026.malone@wampee.canonical.com> Message-ID: <1350195446.3306332.1368780938946.JavaMail.root@redhat.com> Reducing the rounds will simply increase the rate of brute force attacks. sha512_crypt is designed to be slow, it's a feature. If you think there is a problem if too many hashing operations are requested you should rather rate limit the number of hashing requests that can be submitted to the server. Simo. ----- Original Message ----- > Opening so that we can apply the strengthening in a public patch. > > ** Summary changed: > > - passlib long password DoS > + passlib: long passwords trigger long checks > > ** Information type changed from Private Security to Public > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1175906 > > Title: > passlib: long passwords trigger long checks > > Status in OpenStack Identity (Keystone): > New > > Bug description: > Grant Murphy originally reported: > > * Denial of Service > > The passlib restriction of 4096 for maximum password length is > potentially too generous for production environments. On my local machine > the sha512_crypt algorithm with input of 4096 and 40000 > rounds will potentially introduce a DOS problem: > feasible length(128) password encrypt: 0.0707409381866 seconds > feasible length(128) password verify: 0.140727996826 seconds > excessive length(4096) password encrypt: 1.33277702332 seconds > excessive length(4096) password verify: 2.66491699219 seconds > > > I would consider tweaking these values (length or rounds) to reduce > the computational overhead here or you're probably going to have a bad > time. > > If this is exploitable it will need a CVE, if not we should still > harden it so it can't be monkeyed with in the future. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/keystone/+bug/1175906/+subscriptions > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Simo Sorce * Red Hat, Inc. * New York From 1174608 at bugs.launchpad.net Fri May 17 09:56:04 2013 From: 1174608 at bugs.launchpad.net (Bernhard M. Wiedemann) Date: Fri, 17 May 2013 09:56:04 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130517095605.15449.99907.malone@chaenomeles.canonical.com> note regression introduced by the nova change: bug 1181157 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Released Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 1175906 at bugs.launchpad.net Fri May 17 13:37:35 2013 From: 1175906 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 17 May 2013 13:37:35 -0000 Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords trigger long checks References: <20130503065128.15095.65477.malonedeb@gac.canonical.com> Message-ID: <20130517133736.20056.1747.launchpad@gac.canonical.com> ** Changed in: keystone Status: New => Confirmed ** Changed in: keystone Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175906 Title: passlib: long passwords trigger long checks Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Denial of Service The passlib restriction of 4096 for maximum password length is potentially too generous for production environments. On my local machine the sha512_crypt algorithm with input of 4096 and 40000 rounds will potentially introduce a DOS problem: feasible length(128) password encrypt: 0.0707409381866 seconds feasible length(128) password verify: 0.140727996826 seconds excessive length(4096) password encrypt: 1.33277702332 seconds excessive length(4096) password verify: 2.66491699219 seconds I would consider tweaking these values (length or rounds) to reduce the computational overhead here or you're probably going to have a bad time. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175906/+subscriptions From 1175906 at bugs.launchpad.net Fri May 17 13:39:42 2013 From: 1175906 at bugs.launchpad.net (OpenStack Hudson) Date: Fri, 17 May 2013 13:39:42 -0000 Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords trigger long checks References: <20130503065128.15095.65477.malonedeb@gac.canonical.com> Message-ID: <20130517133942.919.37707.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/29542 ** Changed in: keystone Status: Confirmed => In Progress ** Changed in: keystone Assignee: (unassigned) => Dolph Mathews (dolph) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175906 Title: passlib: long passwords trigger long checks Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Denial of Service The passlib restriction of 4096 for maximum password length is potentially too generous for production environments. On my local machine the sha512_crypt algorithm with input of 4096 and 40000 rounds will potentially introduce a DOS problem: feasible length(128) password encrypt: 0.0707409381866 seconds feasible length(128) password verify: 0.140727996826 seconds excessive length(4096) password encrypt: 1.33277702332 seconds excessive length(4096) password verify: 2.66491699219 seconds I would consider tweaking these values (length or rounds) to reduce the computational overhead here or you're probably going to have a bad time. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175906/+subscriptions From 1168252 at bugs.launchpad.net Fri May 17 15:33:38 2013 From: 1168252 at bugs.launchpad.net (Matthew Thode) Date: Fri, 17 May 2013 15:33:38 -0000 Subject: [Openstack-security] [Bug 1168252] Re: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com> Message-ID: <20130517153339.636.6238.malone@soybean.canonical.com> fix released for folsom and grizzly, grizzly with the devstack patch and folsom with this patch. diff -Naur keystone-2012.2.4/keystone/config.py keystone-2012.2.4.new/keystone/config.py --- keystone-2012.2.4/keystone/config.py 2013-04-11 15:02:19.000000000 -0400 +++ keystone-2012.2.4.new/keystone/config.py 2013-05-17 11:26:57.557918817 -0400 @@ -110,7 +110,7 @@ group = kw.pop('group', None) return conf.register_cli_opt(cfg.IntOpt(*args, **kw), group=group) -register_str('admin_token', default='ADMIN') +register_str('admin_token', secret=True, default='ADMIN') register_str('bind_host', default='0.0.0.0') register_str('compute_port', default=8774) register_str('admin_port', default=35357) @@ -162,7 +162,7 @@ #ldap register_str('url', group='ldap', default='ldap://localhost') register_str('user', group='ldap', default='dc=Manager,dc=example,dc=com') -register_str('password', group='ldap', default='freeipa4all') +register_str('password', group='ldap', secret=True, default='freeipa4all') register_str('suffix', group='ldap', default='cn=example,cn=com') register_bool('use_dumb_member', group='ldap', default=False) register_str('user_name_attribute', group='ldap', default='sn') ** Package changed: keystone (Gentoo Linux) => gentoo -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1168252 Title: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) Status in devstack - openstack dev environments: Confirmed Status in OpenStack Security Notes: Fix Released Status in Gentoo Linux: Unknown Bug description: The password configuration of LDAP and admin_token in keystone.conf should be secret to protect security information: [ldap] # url = ldap://localhost # user = dc=Manager,dc=example,dc=com # password = None <- should be secrect # suffix = cn=example,cn=com # use_dumb_member = False # allow_subtree_delete = False # dumb_member = cn=dumb,dc=example,dc=com [DEFAULT] admin_token = passw0rd <- should be secrect To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1168252/+subscriptions From 1168252 at bugs.launchpad.net Fri May 17 15:35:03 2013 From: 1168252 at bugs.launchpad.net (Matthew Thode) Date: Fri, 17 May 2013 15:35:03 -0000 Subject: [Openstack-security] [Bug 1168252] References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com> Message-ID: <20130519105933.28561.26332.launchpad@loganberry.canonical.com> fix released for folsom and grizzly, offending ebuilds removed from tree. fixed in keystone-2012.2.4-r3.ebuild and keystone-2013.1.1.ebuild -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1168252 Title: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) Status in devstack - openstack dev environments: Confirmed Status in OpenStack Security Notes: Fix Released Status in Gentoo Linux: Unknown Bug description: The password configuration of LDAP and admin_token in keystone.conf should be secret to protect security information: [ldap] # url = ldap://localhost # user = dc=Manager,dc=example,dc=com # password = None <- should be secrect # suffix = cn=example,cn=com # use_dumb_member = False # allow_subtree_delete = False # dumb_member = cn=dumb,dc=example,dc=com [DEFAULT] admin_token = passw0rd <- should be secrect To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1168252/+subscriptions From sccarlson at paypal.com Mon May 20 15:29:33 2013 From: sccarlson at paypal.com (Carlson, Scott) Date: Mon, 20 May 2013 15:29:33 +0000 Subject: [Openstack-security] Starting/Continuing the PCI Conversation Message-ID: I'd like to start this thread to bring together resources for ensuring that PCI Compliance can be met within the frameworks of an Openstack cloud, specifically in a private cloud environment. I'll start to do some internal management/maintenance of whatever I can find, and then will help to build the documentation necessary to share with others via openstack.org, etc. By way of a short background, I've lead compliance programs for two fortune 500's over the past 5 years, and now am the lead systems/compute architect @ PayPal. Pleasure to meet you all and look forward to moving ahead. -- Scott Carlson - Infrastructure Architect CISSP S-c-c-a-r-l-s-o-n @p-a-y-p-a-l.c-o-m -------------- next part -------------- An HTML attachment was scrubbed... URL: From 938315 at bugs.launchpad.net Tue May 21 00:08:45 2013 From: 938315 at bugs.launchpad.net (OpenStack Hudson) Date: Tue, 21 May 2013 00:08:45 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130521000845.20325.90799.malone@gac.canonical.com> Reviewed: https://review.openstack.org/28702 Committed: http://github.com/openstack/python-keystoneclient/commit/f2e0818bc97bfbeba83f6abbb07909a8debcad77 Submitter: Jenkins Branch: master commit f2e0818bc97bfbeba83f6abbb07909a8debcad77 Author: Pradeep Kilambi Date: Thu May 9 09:29:02 2013 -0700 Allow secure user password update. This patch allows the ability for user password to be updated via a command prompt so the password doesnt show up in the bash history. The prompted password is asked twice to verify the match. If user cntl-D's the prompt a message appears suggesting user to use either of the options to update the password. Fixes: bug#938315 Change-Id: I4271ae569b922f33c34f9b015a7ee6f760414e39 ** Changed in: python-keystoneclient Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: Fix Committed Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From kseifried at redhat.com Wed May 22 08:14:24 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Wed, 22 May 2013 02:14:24 -0600 Subject: [Openstack-security] keystone tokens In-Reply-To: <1368450686.20220.204.camel@willson.li.ssimo.org> References: <1368450686.20220.204.camel@willson.li.ssimo.org> Message-ID: <519C7E60.1080809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/13/2013 07:11 AM, Simo Sorce wrote: > On Sun, 2013-05-12 at 18:31 +0000, Clark, Robert Graham wrote: >> Generally speaking "A DoS from an authenticated user" is a >> _massive_ concern for anyone who has a cloud with unaccountable >> users, such as shared clouds and for public clouds in >> particular. > > Authenticated users usually have many many ways to cause excessive > use of resources. > > If you are concerned about an authenticated user causing DoS I > think the right answer is to look at rate limiting and a monitoring > system that reports which users are abusing the system. It's easy > to (auto?)terminate accounts that are misbehaving. A completely > different class than anonymous DoS. > > simo. Two quick notes: 1) There is resource usage, and then there is resource usage. For example Linux allows me to use cgroups to limit what a user can do in some cases like memory/cpu usage. Obviously if this can be bypassed that would be a problem, which leads to point #2: 2) In situations like keystone/etc the user is causing code/etc to be run as another user. E.g. when I log into OpenStack and enter a huge password the CPU time used to process that password doesn't run as my user, it runs as whatever keystone uses. So if we apply limits to keystone we just end up making it easier often times for a user to DoS keystone (as opposed to the whole server). And depending on the exact nature of the flaw we may or may not have a useful audit trail (e.g. if a user has to connect repeatedly and send mangled data that will show up, but something like the XML hashdos might just be one request). Also the whole term "authenticated users" has bothered me for a long time. It used to be pretty simple, users either paid you to get access, or ere given access because they were part of the organization (e.g. an employee, a student, whatever). So yeah, if someone did something silly you could go club them. But now many services have free signups (openshift.redhat.com, all you need is a valid email address for example) or have massive numbers of users (e.g. a cloud provider) that are not vetted, and not heavily invested (e.g. I can signup for an account for free at most cloud providers, and trigger things like login DoS's without spending any money). So "authenticated user" is no longer a silver bullet. And no, its not always easy to auto terminate an account that is behaving badly. for one thing you have to know which account it is, and even then, what if it is a paying customer who claims they got compromised? You generally don't want to annoy paying customers to much or make it impossible for them to continue paying =). - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQIcBAEBAgAGBQJRnH5gAAoJEBYNRVNeJnmTH5sQALMBvmzjVIfUzGUStyivZxBj tB+jTgGTIwSTH6pXDk/sFODUZqK6N/xADH9rKyvPBTW8FOLz2p5dvMgHHTp4iPu3 lThvpRXbdraAgT4ZhJE46Ymh6fgEW1hOeQKhsymTKYyRJZg58ZUrKVqLvsbYT8hf gNQfMe8UZiGRJEX6hFUH+autfkOygy7CtZ4nll5MvGQY1pgH8ESNHjEvnDV6I0Lg BNk4qud3oD23TfG3/z8NSgnvDsYWFpxgFr5/21SZN7za0/dR2V4H3WvjI8bsinz0 nJ14Fu1zMWwFgby4IKzcHsQKPG1RMExMXf4lj3iBYPYIT9yS+KSw4YpK0HvSSApJ //1lf9KPZPF5KhNI9Q6oapBHuRTIUwOT5ssV6lqKAdKsa88kJL5Lx5+X9ITUA1Cg /sXZ3sMbW9/Oz9xevanN6vKDiXuqDBgFyZkSHWWxs1Upo+mTwvlKwpsu7VYOsCub eZohFBnV5KtUfdgR99CkjBjyGP1nH6F5uWy7Wzv9WiqzKtxYtat5RfRHekWdOq4h 0drEcC4PgPRaKeKEMRg3s8iUEJ8rI7PzqJxZ7LEqdzTLZbNVRXMspUfa/QzO1CA7 6uNXRjT5xDefm7Cb7OIXk0uQl820fMhrSG7MyUMlARYZKRFGG89iGdRpct+9+yf4 caq9u3qlBK4YbvNH8oSc =d2n1 -----END PGP SIGNATURE----- From dhiru at openwall.com Wed May 22 09:35:47 2013 From: dhiru at openwall.com (Dhiru Kholia) Date: Wed, 22 May 2013 09:35:47 -0000 Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords trigger long checks References: <20130503065128.15095.65477.malonedeb@gac.canonical.com> Message-ID: <20130522093547.7021.54934.malone@wampee.canonical.com> I am a bit late to the party but here are my suggestions, 1. Rate limiting should be implemented with a high priority. (e.g. Gmail shows a CAPTCHA if you keep entering wrong password). In KeyStone case, this rate limited should also be applied even if the authentication succeeds, for best results. I am not sure about the "layer" at which these rate limiting features should be implemented though. 2. "iterations" in the hashing algorithm can be reduced by a factor of 25 if the minimum password length is increased by 1. See http://blog.agilebits.com/2012/07/31/1password-is-ready-for-john-the-ripper/ 3. Ideally, a configurable hashing algorithm (like Django's PBKDF2 -HMAC-SHA256 or better) should be used which allows tweaking of the "iterations" parameter to attain the desired balance. * I have written a DoS tool which is able to saturate a KeyStone server with almost zero bandwidth and CPU consumption. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175906 Title: passlib: long passwords trigger long checks Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Denial of Service The passlib restriction of 4096 for maximum password length is potentially too generous for production environments. On my local machine the sha512_crypt algorithm with input of 4096 and 40000 rounds will potentially introduce a DOS problem: feasible length(128) password encrypt: 0.0707409381866 seconds feasible length(128) password verify: 0.140727996826 seconds excessive length(4096) password encrypt: 1.33277702332 seconds excessive length(4096) password verify: 2.66491699219 seconds I would consider tweaking these values (length or rounds) to reduce the computational overhead here or you're probably going to have a bad time. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175906/+subscriptions From d.w.chadwick at kent.ac.uk Wed May 22 10:03:49 2013 From: d.w.chadwick at kent.ac.uk (David Chadwick) Date: Wed, 22 May 2013 11:03:49 +0100 Subject: [Openstack-security] keystone tokens In-Reply-To: <519C7E60.1080809@redhat.com> References: <1368450686.20220.204.camel@willson.li.ssimo.org> <519C7E60.1080809@redhat.com> Message-ID: <519C9805.5080707@kent.ac.uk> Hi Kurt Whilst I dont buy into your arguments about authenticated users causing DOS problems, we have detected the password processing problem that you mention ie. " when I log into OpenStack and enter a huge password the CPU time used to process that password doesn't run as my user ". We have noticed that processing times increase massively for long passwords. But I would see this as a potential DOS attack from an unauthenticated user who is simply using large random passwords with known usernames, rather than a DOS attack from an authenticated user. regards David On 22/05/2013 09:14, Kurt Seifried wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/13/2013 07:11 AM, Simo Sorce wrote: >> On Sun, 2013-05-12 at 18:31 +0000, Clark, Robert Graham wrote: >>> Generally speaking "A DoS from an authenticated user" is a >>> _massive_ concern for anyone who has a cloud with unaccountable >>> users, such as shared clouds and for public clouds in >>> particular. >> >> Authenticated users usually have many many ways to cause excessive >> use of resources. >> >> If you are concerned about an authenticated user causing DoS I >> think the right answer is to look at rate limiting and a monitoring >> system that reports which users are abusing the system. It's easy >> to (auto?)terminate accounts that are misbehaving. A completely >> different class than anonymous DoS. >> >> simo. > > Two quick notes: > > 1) There is resource usage, and then there is resource usage. For > example Linux allows me to use cgroups to limit what a user can do in > some cases like memory/cpu usage. Obviously if this can be bypassed > that would be a problem, which leads to point #2: > > 2) In situations like keystone/etc the user is causing code/etc to be > run as another user. E.g. when I log into OpenStack and enter a huge > password the CPU time used to process that password doesn't run as my > user, it runs as whatever keystone uses. So if we apply limits to > keystone we just end up making it easier often times for a user to DoS > keystone (as opposed to the whole server). > > And depending on the exact nature of the flaw we may or may not have a > useful audit trail (e.g. if a user has to connect repeatedly and send > mangled data that will show up, but something like the XML hashdos > might just be one request). > > Also the whole term "authenticated users" has bothered me for a long > time. It used to be pretty simple, users either paid you to get > access, or ere given access because they were part of the organization > (e.g. an employee, a student, whatever). So yeah, if someone did > something silly you could go club them. But now many services have > free signups (openshift.redhat.com, all you need is a valid email > address for example) or have massive numbers of users (e.g. a cloud > provider) that are not vetted, and not heavily invested (e.g. I can > signup for an account for free at most cloud providers, and trigger > things like login DoS's without spending any money). So "authenticated > user" is no longer a silver bullet. > > And no, its not always easy to auto terminate an account that is > behaving badly. for one thing you have to know which account it is, > and even then, what if it is a paying customer who claims they got > compromised? You generally don't want to annoy paying customers to > much or make it impossible for them to continue paying =). > > - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.13 (GNU/Linux) > > iQIcBAEBAgAGBQJRnH5gAAoJEBYNRVNeJnmTH5sQALMBvmzjVIfUzGUStyivZxBj > tB+jTgGTIwSTH6pXDk/sFODUZqK6N/xADH9rKyvPBTW8FOLz2p5dvMgHHTp4iPu3 > lThvpRXbdraAgT4ZhJE46Ymh6fgEW1hOeQKhsymTKYyRJZg58ZUrKVqLvsbYT8hf > gNQfMe8UZiGRJEX6hFUH+autfkOygy7CtZ4nll5MvGQY1pgH8ESNHjEvnDV6I0Lg > BNk4qud3oD23TfG3/z8NSgnvDsYWFpxgFr5/21SZN7za0/dR2V4H3WvjI8bsinz0 > nJ14Fu1zMWwFgby4IKzcHsQKPG1RMExMXf4lj3iBYPYIT9yS+KSw4YpK0HvSSApJ > //1lf9KPZPF5KhNI9Q6oapBHuRTIUwOT5ssV6lqKAdKsa88kJL5Lx5+X9ITUA1Cg > /sXZ3sMbW9/Oz9xevanN6vKDiXuqDBgFyZkSHWWxs1Upo+mTwvlKwpsu7VYOsCub > eZohFBnV5KtUfdgR99CkjBjyGP1nH6F5uWy7Wzv9WiqzKtxYtat5RfRHekWdOq4h > 0drEcC4PgPRaKeKEMRg3s8iUEJ8rI7PzqJxZ7LEqdzTLZbNVRXMspUfa/QzO1CA7 > 6uNXRjT5xDefm7Cb7OIXk0uQl820fMhrSG7MyUMlARYZKRFGG89iGdRpct+9+yf4 > caq9u3qlBK4YbvNH8oSc > =d2n1 > -----END PGP SIGNATURE----- > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From robert.clark at hp.com Wed May 22 11:00:13 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 22 May 2013 11:00:13 +0000 Subject: [Openstack-security] keystone tokens In-Reply-To: <519C9805.5080707@kent.ac.uk> Message-ID: David, Can you elaborate on what you "don't buy", is it that authenticated user attacks aren't a problem or that something should be throttling their actions before they interact with keystone? On 22/05/2013 11:03, "David Chadwick" wrote: >Hi Kurt >Whilst I dont buy into your arguments about authenticated users causing >DOS problems, we have detected the password processing problem that you >mention ie. >" when I log into OpenStack and enter a huge password the CPU time used >to process that password doesn't run as my user ". We have noticed that >processing times increase massively for long passwords. But I would see >this as a potential DOS attack from an unauthenticated user who is >simply using large random passwords with known usernames, rather than a >DOS attack from an authenticated user. > >regards > >David > >On 22/05/2013 09:14, Kurt Seifried wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 05/13/2013 07:11 AM, Simo Sorce wrote: >>> On Sun, 2013-05-12 at 18:31 +0000, Clark, Robert Graham wrote: >>>> Generally speaking "A DoS from an authenticated user" is a >>>> _massive_ concern for anyone who has a cloud with unaccountable >>>> users, such as shared clouds and for public clouds in >>>> particular. >>> >>> Authenticated users usually have many many ways to cause excessive >>> use of resources. >>> >>> If you are concerned about an authenticated user causing DoS I >>> think the right answer is to look at rate limiting and a monitoring >>> system that reports which users are abusing the system. It's easy >>> to (auto?)terminate accounts that are misbehaving. A completely >>> different class than anonymous DoS. >>> >>> simo. >> >> Two quick notes: >> >> 1) There is resource usage, and then there is resource usage. For >> example Linux allows me to use cgroups to limit what a user can do in >> some cases like memory/cpu usage. Obviously if this can be bypassed >> that would be a problem, which leads to point #2: >> >> 2) In situations like keystone/etc the user is causing code/etc to be >> run as another user. E.g. when I log into OpenStack and enter a huge >> password the CPU time used to process that password doesn't run as my >> user, it runs as whatever keystone uses. So if we apply limits to >> keystone we just end up making it easier often times for a user to DoS >> keystone (as opposed to the whole server). >> >> And depending on the exact nature of the flaw we may or may not have a >> useful audit trail (e.g. if a user has to connect repeatedly and send >> mangled data that will show up, but something like the XML hashdos >> might just be one request). >> >> Also the whole term "authenticated users" has bothered me for a long >> time. It used to be pretty simple, users either paid you to get >> access, or ere given access because they were part of the organization >> (e.g. an employee, a student, whatever). So yeah, if someone did >> something silly you could go club them. But now many services have >> free signups (openshift.redhat.com, all you need is a valid email >> address for example) or have massive numbers of users (e.g. a cloud >> provider) that are not vetted, and not heavily invested (e.g. I can >> signup for an account for free at most cloud providers, and trigger >> things like login DoS's without spending any money). So "authenticated >> user" is no longer a silver bullet. >> >> And no, its not always easy to auto terminate an account that is >> behaving badly. for one thing you have to know which account it is, >> and even then, what if it is a paying customer who claims they got >> compromised? You generally don't want to annoy paying customers to >> much or make it impossible for them to continue paying =). >> >> - -- >> Kurt Seifried Red Hat Security Response Team (SRT) >> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.13 (GNU/Linux) >> >> iQIcBAEBAgAGBQJRnH5gAAoJEBYNRVNeJnmTH5sQALMBvmzjVIfUzGUStyivZxBj >> tB+jTgGTIwSTH6pXDk/sFODUZqK6N/xADH9rKyvPBTW8FOLz2p5dvMgHHTp4iPu3 >> lThvpRXbdraAgT4ZhJE46Ymh6fgEW1hOeQKhsymTKYyRJZg58ZUrKVqLvsbYT8hf >> gNQfMe8UZiGRJEX6hFUH+autfkOygy7CtZ4nll5MvGQY1pgH8ESNHjEvnDV6I0Lg >> BNk4qud3oD23TfG3/z8NSgnvDsYWFpxgFr5/21SZN7za0/dR2V4H3WvjI8bsinz0 >> nJ14Fu1zMWwFgby4IKzcHsQKPG1RMExMXf4lj3iBYPYIT9yS+KSw4YpK0HvSSApJ >> //1lf9KPZPF5KhNI9Q6oapBHuRTIUwOT5ssV6lqKAdKsa88kJL5Lx5+X9ITUA1Cg >> /sXZ3sMbW9/Oz9xevanN6vKDiXuqDBgFyZkSHWWxs1Upo+mTwvlKwpsu7VYOsCub >> eZohFBnV5KtUfdgR99CkjBjyGP1nH6F5uWy7Wzv9WiqzKtxYtat5RfRHekWdOq4h >> 0drEcC4PgPRaKeKEMRg3s8iUEJ8rI7PzqJxZ7LEqdzTLZbNVRXMspUfa/QzO1CA7 >> 6uNXRjT5xDefm7Cb7OIXk0uQl820fMhrSG7MyUMlARYZKRFGG89iGdRpct+9+yf4 >> caq9u3qlBK4YbvNH8oSc >> =d2n1 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From d.w.chadwick at kent.ac.uk Wed May 22 11:37:21 2013 From: d.w.chadwick at kent.ac.uk (David Chadwick) Date: Wed, 22 May 2013 12:37:21 +0100 Subject: [Openstack-security] keystone tokens In-Reply-To: References: Message-ID: <519CADF1.3080902@kent.ac.uk> Two reasons 1. I think that some of your arguments (like long pw) were really unauthenticated not authenticated user arguments which can be used by any attackers, and 2. I think that a cloud service that offers free services to anyone with any email address is not really an authenticated user service, its more like a public service for everyone, where everyone is allowed to go back to their own specific stake in the cloud. So the users have not been identified and authenticated in any real sense. Its an OpenID, level of assurance =1, type of service, where all the cloud can be assured of, is that is it probably the same user every time, but it has no idea of who this user is. regards David On 22/05/2013 12:00, Clark, Robert Graham wrote: > David, > > Can you elaborate on what you "don't buy", is it that authenticated user > attacks aren't a problem or that something should be throttling their > actions before they interact with keystone? > > On 22/05/2013 11:03, "David Chadwick" wrote: > >> Hi Kurt >> Whilst I dont buy into your arguments about authenticated users causing >> DOS problems, we have detected the password processing problem that you >> mention ie. >> " when I log into OpenStack and enter a huge password the CPU time used >> to process that password doesn't run as my user ". We have noticed that >> processing times increase massively for long passwords. But I would see >> this as a potential DOS attack from an unauthenticated user who is >> simply using large random passwords with known usernames, rather than a >> DOS attack from an authenticated user. >> >> regards >> >> David >> >> On 22/05/2013 09:14, Kurt Seifried wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 05/13/2013 07:11 AM, Simo Sorce wrote: >>>> On Sun, 2013-05-12 at 18:31 +0000, Clark, Robert Graham wrote: >>>>> Generally speaking "A DoS from an authenticated user" is a >>>>> _massive_ concern for anyone who has a cloud with unaccountable >>>>> users, such as shared clouds and for public clouds in >>>>> particular. >>>> >>>> Authenticated users usually have many many ways to cause excessive >>>> use of resources. >>>> >>>> If you are concerned about an authenticated user causing DoS I >>>> think the right answer is to look at rate limiting and a monitoring >>>> system that reports which users are abusing the system. It's easy >>>> to (auto?)terminate accounts that are misbehaving. A completely >>>> different class than anonymous DoS. >>>> >>>> simo. >>> >>> Two quick notes: >>> >>> 1) There is resource usage, and then there is resource usage. For >>> example Linux allows me to use cgroups to limit what a user can do in >>> some cases like memory/cpu usage. Obviously if this can be bypassed >>> that would be a problem, which leads to point #2: >>> >>> 2) In situations like keystone/etc the user is causing code/etc to be >>> run as another user. E.g. when I log into OpenStack and enter a huge >>> password the CPU time used to process that password doesn't run as my >>> user, it runs as whatever keystone uses. So if we apply limits to >>> keystone we just end up making it easier often times for a user to DoS >>> keystone (as opposed to the whole server). >>> >>> And depending on the exact nature of the flaw we may or may not have a >>> useful audit trail (e.g. if a user has to connect repeatedly and send >>> mangled data that will show up, but something like the XML hashdos >>> might just be one request). >>> >>> Also the whole term "authenticated users" has bothered me for a long >>> time. It used to be pretty simple, users either paid you to get >>> access, or ere given access because they were part of the organization >>> (e.g. an employee, a student, whatever). So yeah, if someone did >>> something silly you could go club them. But now many services have >>> free signups (openshift.redhat.com, all you need is a valid email >>> address for example) or have massive numbers of users (e.g. a cloud >>> provider) that are not vetted, and not heavily invested (e.g. I can >>> signup for an account for free at most cloud providers, and trigger >>> things like login DoS's without spending any money). So "authenticated >>> user" is no longer a silver bullet. >>> >>> And no, its not always easy to auto terminate an account that is >>> behaving badly. for one thing you have to know which account it is, >>> and even then, what if it is a paying customer who claims they got >>> compromised? You generally don't want to annoy paying customers to >>> much or make it impossible for them to continue paying =). >>> >>> - -- >>> Kurt Seifried Red Hat Security Response Team (SRT) >>> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.13 (GNU/Linux) >>> >>> iQIcBAEBAgAGBQJRnH5gAAoJEBYNRVNeJnmTH5sQALMBvmzjVIfUzGUStyivZxBj >>> tB+jTgGTIwSTH6pXDk/sFODUZqK6N/xADH9rKyvPBTW8FOLz2p5dvMgHHTp4iPu3 >>> lThvpRXbdraAgT4ZhJE46Ymh6fgEW1hOeQKhsymTKYyRJZg58ZUrKVqLvsbYT8hf >>> gNQfMe8UZiGRJEX6hFUH+autfkOygy7CtZ4nll5MvGQY1pgH8ESNHjEvnDV6I0Lg >>> BNk4qud3oD23TfG3/z8NSgnvDsYWFpxgFr5/21SZN7za0/dR2V4H3WvjI8bsinz0 >>> nJ14Fu1zMWwFgby4IKzcHsQKPG1RMExMXf4lj3iBYPYIT9yS+KSw4YpK0HvSSApJ >>> //1lf9KPZPF5KhNI9Q6oapBHuRTIUwOT5ssV6lqKAdKsa88kJL5Lx5+X9ITUA1Cg >>> /sXZ3sMbW9/Oz9xevanN6vKDiXuqDBgFyZkSHWWxs1Upo+mTwvlKwpsu7VYOsCub >>> eZohFBnV5KtUfdgR99CkjBjyGP1nH6F5uWy7Wzv9WiqzKtxYtat5RfRHekWdOq4h >>> 0drEcC4PgPRaKeKEMRg3s8iUEJ8rI7PzqJxZ7LEqdzTLZbNVRXMspUfa/QzO1CA7 >>> 6uNXRjT5xDefm7Cb7OIXk0uQl820fMhrSG7MyUMlARYZKRFGG89iGdRpct+9+yf4 >>> caq9u3qlBK4YbvNH8oSc >>> =d2n1 >>> -----END PGP SIGNATURE----- >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From simo at redhat.com Wed May 22 12:38:43 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 22 May 2013 08:38:43 -0400 Subject: [Openstack-security] keystone tokens In-Reply-To: <519CADF1.3080902@kent.ac.uk> References: <519CADF1.3080902@kent.ac.uk> Message-ID: <1369226323.23339.38.camel@willson.li.ssimo.org> On Wed, 2013-05-22 at 12:37 +0100, David Chadwick wrote: > Two reasons > > 1. I think that some of your arguments (like long pw) were really > unauthenticated not authenticated user arguments which can be used by > any attackers, and > > 2. I think that a cloud service that offers free services to anyone with > any email address is not really an authenticated user service, its more > like a public service for everyone, where everyone is allowed to go back > to their own specific stake in the cloud. So the users have not been > identified and authenticated in any real sense. Its an OpenID, level of > assurance =1, type of service, where all the cloud can be assured of, is > that is it probably the same user every time, but it has no idea of who > this user is. In both cases you can throttle either by IP or by user name. I bet there are many other expensive operations a user can perform. If there is no throttling a user can simply perform N more operations to reach the same load on keystone. Unless there is some form of throttling you cannot really defend to this kind of DoS attacks. Simo. -- Simo Sorce * Red Hat, Inc * New York From fungi at yuggoth.org Wed May 22 15:32:35 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 22 May 2013 15:32:35 +0000 Subject: [Openstack-security] keystone tokens In-Reply-To: <519CADF1.3080902@kent.ac.uk> References: <519CADF1.3080902@kent.ac.uk> Message-ID: <20130522153234.GY1472@yuggoth.org> On 2013-05-22 12:37:21 +0100 (+0100), David Chadwick wrote: > On 22/05/2013 12:00, Clark, Robert Graham wrote: > > On 22/05/2013 11:03, "David Chadwick" wrote: > > > On 22/05/2013 09:14, Kurt Seifried wrote: [...] > > > > Also the whole term "authenticated users" has bothered me > > > > for a long time. It used to be pretty simple, users either > > > > paid you to get access, or ere given access because they > > > > were part of the organization (e.g. an employee, a student, > > > > whatever). So yeah, if someone did something silly you could > > > > go club them. But now many services have free signups > > > > (openshift.redhat.com, all you need is a valid email address > > > > for example) or have massive numbers of users (e.g. a cloud > > > > provider) that are not vetted, and not heavily invested > > > > (e.g. I can signup for an account for free at most cloud > > > > providers, and trigger things like login DoS's without > > > > spending any money). So "authenticated user" is no longer a > > > > silver bullet. [...] > > > I dont buy into your arguments about authenticated users > > > causing DOS problems [...] > > Can you elaborate on what you "don't buy", is it that > > authenticated user attacks aren't a problem or that something > > should be throttling their actions before they interact with > > keystone? [...] > 1. I think that some of your arguments (like long pw) were really > unauthenticated [...] > 2. I think that a cloud service that offers free services to > anyone with any email address is not really an authenticated user > service [...] Looks to me like you're in violent agreement with the point Kurt was making. With low/no-investment sign-ups, authenticated users aren't really authenticated in any useful sense. -- Jeremy Stanley From fungi at yuggoth.org Wed May 22 20:01:22 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 22 May 2013 20:01:22 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130522200122.20462.45274.malone@gac.canonical.com> Proposed impact description... Title: Keystone client local information disclosure Reporter: Jake Dahn (Nebula) Products: python-keystoneclient Affects: All versions Description: Jake Dahn from Nebula reported a vulnerability that the keystone client only allows passwords to be updated in a clear text command-line argument, which may enable other local users to obtain sensitive information by listing the process and potentially leaves a record of the password within the shell command history. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: Fix Committed Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From thierry.carrez+lp at gmail.com Wed May 22 20:12:11 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 22 May 2013 20:12:11 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130522201211.7496.54325.malone@wampee.canonical.com> +1 to impact desc -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: Fix Committed Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From 938315 at bugs.launchpad.net Wed May 22 20:18:11 2013 From: 938315 at bugs.launchpad.net (Russell Bryant) Date: Wed, 22 May 2013 20:18:11 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130522201811.667.14800.malone@soybean.canonical.com> +1, description sounds good to me, too -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: Updating password via keystoneclient CLI should be done securely. Status in Python client library for Keystone: Fix Committed Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/938315/+subscriptions From john at johngarbutt.com Wed May 22 11:22:16 2013 From: john at johngarbutt.com (John Garbutt) Date: Wed, 22 May 2013 11:22:16 -0000 Subject: [Openstack-security] [Bug 1074087] Re: XenApi migration driver should use execvp References: <20121101174933.5279.14962.malonedeb@gac.canonical.com> Message-ID: <20130522112217.1084.51880.launchpad@soybean.canonical.com> ** Tags added: xenserver ** Changed in: nova Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1074087 Title: XenApi migration driver should use execvp Status in OpenStack Compute (Nova): Triaged Bug description: The XenApi drivers split a string to create an array for subprocess.Popen, rather than passing an array directly. This invites the potential for command injection / manipulation. There is no clearly valid reason to use string splitting here when arguments can be passed, as elsewhere, directly into Popen. The behavior here is present in current Trunk, Folsom, and Essex. Per Trunk and Folsom, _rsync_vhds calls plugins.utils.subprocess to perform the splitting. In Essex, this behaviorism was present directly in migration/transfer_vhd.py, rather than in utils.py. Earlier releases have not been evaluated. I am not certain if this is directly exploitable. The user field is inserted into the generated strings used for command-line execution, and it does seem that Keystone allows usernames to contain arbitrary tokens/characters such as spaces. It is not clear to me if the user field directly matches that in Keystone, if the user field is otherwise validated in the API, etc. Other fields inserted into the command string seem to be internally generated. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1074087/+subscriptions From thierry.carrez+lp at gmail.com Fri May 24 10:10:58 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 24 May 2013 10:10:58 -0000 Subject: [Openstack-security] [Bug 938315] Re: Updating password via keystoneclient CLI should be done securely. References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130524101059.26018.68995.malone@wampee.canonical.com> OSSA-2013-013. Still needs to be pushed to openstack-announce. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Importance: Undecided => Low ** Changed in: ossa Status: New => Fix Committed ** Changed in: ossa Assignee: (unassigned) => Jeremy Stanley (fungi) ** Summary changed: - Updating password via keystoneclient CLI should be done securely. + [OSSA-2013-013] Updating password via keystoneclient CLI should be done securely -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: [OSSA-2013-013] Updating password via keystoneclient CLI should be done securely Status in OpenStack Security Advisories: Fix Committed Status in Python client library for Keystone: Fix Committed Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/938315/+subscriptions From fungi at yuggoth.org Fri May 24 12:41:37 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 24 May 2013 12:41:37 -0000 Subject: [Openstack-security] [Bug 938315] Re: [OSSA-2013-013] Updating password via keystoneclient CLI should be done securely References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130524124139.27387.15333.launchpad@gac.canonical.com> ** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: [OSSA-2013-013] Updating password via keystoneclient CLI should be done securely Status in OpenStack Security Advisories: Fix Released Status in Python client library for Keystone: Fix Committed Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/938315/+subscriptions From thierry.carrez+lp at gmail.com Fri May 24 12:48:51 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 24 May 2013 12:48:51 -0000 Subject: [Openstack-security] [Bug 1174608] Re: Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130524124851.26416.60805.launchpad@wampee.canonical.com> ** Also affects: ossa Importance: Undecided Status: New ** Summary changed: - Insecure directory creation for signing + [OSSA 2013-010] Insecure directory creation for signing ** Changed in: ossa Status: New => Fix Released ** Changed in: ossa Assignee: (unassigned) => Thierry Carrez (ttx) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: [OSSA 2013-010] Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Released Status in OpenStack Security Advisories: Fix Released Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From stackerandrew at gmail.com Mon May 27 07:43:37 2013 From: stackerandrew at gmail.com (Andrew finley) Date: Mon, 27 May 2013 13:13:37 +0530 Subject: [Openstack-security] Reg: Security concern Message-ID: Hi There, I've been working with nova, glance and keystone for past one year and now i want to look into swift to implement in production level, which raises a question about security concern with openstack where i found this group. So how secure is swift as of now, i've been reading mailing lists and disussions about man-in-middle attack can be performed, any suggestions? Regards, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prometheanfire at gentoo.org Mon May 27 08:09:33 2013 From: prometheanfire at gentoo.org (Matthew Thode) Date: Mon, 27 May 2013 03:09:33 -0500 Subject: [Openstack-security] Reg: Security concern In-Reply-To: References: Message-ID: <51A314BD.8030002@gentoo.org> On 05/27/13 02:43, Andrew finley wrote: > Hi There, > > I've been working with nova, glance and keystone for past one year and > now i want to look into swift to implement in production level, which > raises a question about security concern with openstack where i found this > group. So how secure is swift as of now, i've been reading mailing lists > and disussions about man-in-middle attack can be performed, any suggestions? > > Regards, > Andrew. > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > I don't know of any security concerns with swift, maybe a mitm can happen if you don't use ssl, but I don't know of anything otherwise. -- -- Matthew Thode (prometheanfire) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From thierry at openstack.org Mon May 27 10:03:46 2013 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 27 May 2013 12:03:46 +0200 Subject: [Openstack-security] Reg: Security concern In-Reply-To: <51A314BD.8030002@gentoo.org> References: <51A314BD.8030002@gentoo.org> Message-ID: <51A32F82.6070605@openstack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Matthew Thode wrote: >> I've been working with nova, glance and keystone for past one >> year and now i want to look into swift to implement in production >> level, which raises a question about security concern with >> openstack where i found this group. So how secure is swift as of >> now, i've been reading mailing lists and disussions about >> man-in-middle attack can be performed, any suggestions? Swift is quite secure but has a number of deployment assumptions which may or may not be acceptable for you: you need to rely of external SSL termination (generally at the load balancing boundary), and the Swift internal deployment network (over which the various nodes communicate) is considered trusted. Hope this helps. - -- Thierry Carrez (ttx) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRoy9/AAoJEFB6+JAlsQQjj7oQALceddNGw48palzJIf5/N+Nz 8M6AuCBNCTvXHZtuYYmM1aNQfAkQxET3tepOaxu+Zwjcs3z9zBl94vQFJmoF5p2Y 7FX+7lJzk8bYn7jyYoTEsjBJYS3k2RHP3RLv94jtXRSGMUbe/CdjgRGse+upIOl7 6Jkz0edktCC5ZYV4eO2fCUc9g2KWotuvsJ4gvZ3LroF+JeQgmESUe+Sivz0ZT2fG VGEjYYRswHP+q2VXMEgROXBUgfE0brVZHtGCl6kA0zavT76IeB1j7yfF9zGeAlhr 4p/5y66y1yggAVV9v0bbU9rPapLqz/VbKlKS03llgSARgWLIeH36OXyNgjrc+zdH 6s9FSRc0sHWd9H4C3BOo7WmeoNwan5bPEw/qEsDRqouEnxw6ZoumRIhtybv1M7YU +zHG5Vrd23sVnepqub7u6fQZ3wlXL09HCRR7STc6mnx2zk/uSyiaxqkUv7AHUWGd dtVb38XYEHIJ62P1u4gJsZLYRfPbv9SVS9JmP7rQiWqNbpHfFhRrGhsjyu8+gA66 0VQdukYu+xsF9crLxt1OcFXu6beNj0xojRQwyAfw8C+29RPTh2ULz/uMoNZJsTJu MejJj0VOTOxc5MdQhBYKvFdzE1G1YNm1pjbBRNcWm1cg1O29P2fTDRKxNqI9450w hLddhrZFj/UOG4E7+jaH =TBM+ -----END PGP SIGNATURE----- From stackerandrew at gmail.com Mon May 27 11:37:41 2013 From: stackerandrew at gmail.com (Andrew finley) Date: Mon, 27 May 2013 17:07:41 +0530 Subject: [Openstack-security] Reg: Security concern In-Reply-To: <51A314BD.8030002@gentoo.org> References: <51A314BD.8030002@gentoo.org> Message-ID: so you mean to say, i need to use a ssl tunnel to connect to swift while uploading content? do you have any example setups to test this? or any online documents to use ssl with swift? On Mon, May 27, 2013 at 1:39 PM, Matthew Thode wrote: > On 05/27/13 02:43, Andrew finley wrote: > > Hi There, > > > > I've been working with nova, glance and keystone for past one year and > > now i want to look into swift to implement in production level, which > > raises a question about security concern with openstack where i found > this > > group. So how secure is swift as of now, i've been reading mailing lists > > and disussions about man-in-middle attack can be performed, any > suggestions? > > > > Regards, > > Andrew. > > > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > I don't know of any security concerns with swift, maybe a mitm can > happen if you don't use ssl, but I don't know of anything otherwise. > > -- > -- Matthew Thode (prometheanfire) > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Tue May 28 11:17:28 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 28 May 2013 11:17:28 +0000 Subject: [Openstack-security] Reg: Security concern In-Reply-To: Message-ID: Swift, like many OpenStack products is reasonably secure at the edge (providing sensible deployment decisions are made) but much more vulnerable internally. A malicious attacker inside of your production network can attack a number of weak points in the architecture. In many places security can be improved at the cost of performance, a good example being internal SSL between hosts. The hardening guide (being worked on this June) will address these pain points and provide guidance on secure deployment. -Rob From: Andrew finley > Date: Monday, 27 May 2013 12:37 To: "prometheanfire at gentoo.org" > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] Reg: Security concern so you mean to say, i need to use a ssl tunnel to connect to swift while uploading content? do you have any example setups to test this? or any online documents to use ssl with swift? On Mon, May 27, 2013 at 1:39 PM, Matthew Thode > wrote: On 05/27/13 02:43, Andrew finley wrote: > Hi There, > > I've been working with nova, glance and keystone for past one year and > now i want to look into swift to implement in production level, which > raises a question about security concern with openstack where i found this > group. So how secure is swift as of now, i've been reading mailing lists > and disussions about man-in-middle attack can be performed, any suggestions? > > Regards, > Andrew. > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > I don't know of any security concerns with swift, maybe a mitm can happen if you don't use ssl, but I don't know of anything otherwise. -- -- Matthew Thode (prometheanfire) _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From thierry.carrez+lp at gmail.com Wed May 29 08:33:02 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 29 May 2013 08:33:02 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20130529083304.1169.93744.launchpad@gac.canonical.com> ** Changed in: nova Milestone: havana-1 => havana-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (Nova): In Progress Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From thierry.carrez+lp at gmail.com Wed May 29 08:47:26 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 29 May 2013 08:47:26 -0000 Subject: [Openstack-security] [Bug 1172195] Re: admin_token and LDAP password show up in log in DEBUG mode References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com> Message-ID: <20130529084728.1555.73485.launchpad@gac.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => havana-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1172195 Title: admin_token and LDAP password show up in log in DEBUG mode Status in OpenStack Identity (Keystone): Fix Released Status in Keystone grizzly series: Fix Released Bug description: This is a by-product of bug 1168252. Keystone auth_token and LDAP password are not market "secret" so they appear in DEBUG level logs: (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token = 111222333444 (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password = None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1172195/+subscriptions From thierry.carrez+lp at gmail.com Wed May 29 10:17:40 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 29 May 2013 10:17:40 -0000 Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130529101744.12707.95571.launchpad@soybean.canonical.com> ** Changed in: nova Status: Fix Committed => Fix Released ** Changed in: nova Milestone: None => havana-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: [OSSA 2013-010] Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Released Status in OpenStack Security Advisories: Fix Released Status in Python client library for Keystone: Fix Committed Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From 938315 at bugs.launchpad.net Wed May 29 16:39:22 2013 From: 938315 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 29 May 2013 16:39:22 -0000 Subject: [Openstack-security] [Bug 938315] Re: [OSSA-2013-013] Updating password via keystoneclient CLI should be done securely References: <20120222005440.9777.21681.malonedeb@gac.canonical.com> Message-ID: <20130529163924.23072.84753.launchpad@wampee.canonical.com> ** Changed in: python-keystoneclient Milestone: None => 0.2.4 ** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/938315 Title: [OSSA-2013-013] Updating password via keystoneclient CLI should be done securely Status in OpenStack Security Advisories: Fix Released Status in Python client library for Keystone: Fix Released Bug description: Updating password via CLI should be done via a secure password prompt, not text. current: keystone user-password-update --user=jake --password=foo expected: keystone user-password-update --user=jake Password: Repeat Password: To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/938315/+subscriptions From 1174608 at bugs.launchpad.net Wed May 29 16:47:36 2013 From: 1174608 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 29 May 2013 16:47:36 -0000 Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20130529164739.26193.73975.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Milestone: None => 0.2.4 ** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: [OSSA 2013-010] Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Released Status in OpenStack Security Advisories: Fix Released Status in Python client library for Keystone: Fix Released Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From gerrit2 at review.openstack.org Thu May 30 00:00:20 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 May 2013 00:00:20 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/30973 Log: commit 4501821c9728dcb1f7a741b70537ffa03e3e53a0 Author: Joel Coffman Date: Wed May 29 19:09:35 2013 -0400 Create key manager interface The key manager interface is used by the volume encryption code to retrieve keys for volumes. Implements: blueprint encrypt-cinder-volumes Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 SecurityImpact From gerrit2 at review.openstack.org Thu May 30 00:03:18 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 May 2013 00:03:18 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I164290e761a9922919a70f22f99af70dac213b61 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/30974 Log: commit 2498510115f879e2e7ee71a9df6a4a5f57084d33 Author: Joel Coffman Date: Wed May 15 17:27:42 2013 -0400 Add encryption metadata to volume table This modification adds an encryption key UUID field to the volume table, which is sufficient to make Cinder "aware" of encrypted volumes as designated by predefined volume types. Integration with a key manager is necessary to obtain an actual encryption key UUID (the current implementation generates a random UUID when an encrypted volumes is created). Cinder should *not* presume that it necessarily will have access to the key itself -- this decision depends upon the design, implementation, and policy for encrypted volumes. The key's UUID is stored in Cinder because it is metadata about the volume. Implements: blueprint encrypt-cinder-volumes Change-Id: I164290e761a9922919a70f22f99af70dac213b61 SecurityImpact From gerrit2 at review.openstack.org Thu May 30 00:09:04 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 May 2013 00:09:04 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I358813b3ecde4f88de7202c1c07d9b1168c2c332 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/30976 Log: commit f101a77ae47b785813bda36fa1f27641a3a61e71 Author: Joel Coffman Date: Wed May 29 19:14:56 2013 -0400 Add encryption support for volumes Add support to encrypt Cinder volumes. Modified the libvirt driver to encrypt volumes during the attach call. Created a new VolumeEncryptor class that is responsible for encrypting volumes. The default implementation does not do enryption, and a DmCryptVolumeEncryptor is provided to encrypt volumes using dmcrypt. Implements: blueprint encrypt-cinder-volumes Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332 SecurityImpact From thierry.carrez+lp at gmail.com Thu May 30 09:16:49 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 May 2013 09:16:49 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20130530091649.27698.84023.launchpad@gac.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: Triaged Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From simo at redhat.com Thu May 30 14:03:08 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 30 May 2013 10:03:08 -0400 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 In-Reply-To: References: Message-ID: <1369922588.2769.160.camel@willson.li.ssimo.org> On Thu, 2013-05-30 at 00:00 +0000, gerrit2 at review.openstack.org wrote: > Hi, I'd like you to take a look at this patch for potential > SecurityImpact. > https://review.openstack.org/30973 > > Log: > commit 4501821c9728dcb1f7a741b70537ffa03e3e53a0 > Author: Joel Coffman > Date: Wed May 29 19:09:35 2013 -0400 > > Create key manager interface > > The key manager interface is used by the volume encryption code to retrieve > keys for volumes. > > Implements: blueprint encrypt-cinder-volumes > Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 > SecurityImpact Is there a good reason why access to the review is restricted ? (I can't access it) Simo. -- Simo Sorce * Red Hat, Inc * New York From rbryant at redhat.com Thu May 30 14:13:48 2013 From: rbryant at redhat.com (Russell Bryant) Date: Thu, 30 May 2013 10:13:48 -0400 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 In-Reply-To: <1369922588.2769.160.camel@willson.li.ssimo.org> References: <1369922588.2769.160.camel@willson.li.ssimo.org> Message-ID: <51A75E9C.3040100@redhat.com> On 05/30/2013 10:03 AM, Simo Sorce wrote: > On Thu, 2013-05-30 at 00:00 +0000, gerrit2 at review.openstack.org wrote: >> Hi, I'd like you to take a look at this patch for potential >> SecurityImpact. >> https://review.openstack.org/30973 >> >> Log: >> commit 4501821c9728dcb1f7a741b70537ffa03e3e53a0 >> Author: Joel Coffman >> Date: Wed May 29 19:09:35 2013 -0400 >> >> Create key manager interface >> >> The key manager interface is used by the volume encryption code to retrieve >> keys for volumes. >> >> Implements: blueprint encrypt-cinder-volumes >> Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 >> SecurityImpact > > Is there a good reason why access to the review is restricted ? > (I can't access it) I can't see it either. That's usually because a change is marked as a DRAFT. Only specific people you add can see a DRAFT. A public equivalent status is to mark it as Work-in-progress. -- Russell Bryant From fungi at yuggoth.org Thu May 30 19:05:34 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 30 May 2013 19:05:34 -0000 Subject: [Openstack-security] [Bug 1185905] Re: User tokens logged by keystoneclient.middleware.auth_token References: <20130530172146.6036.96318.malonedeb@chaenomeles.canonical.com> Message-ID: <20130530190534.5814.42985.malone@chaenomeles.canonical.com> *** This bug is a duplicate of bug 1004114 *** https://bugs.launchpad.net/bugs/1004114 I think this is one of the facets of the debug-level credential logging which is being solved several ways in different places? Marking as a duplicate of bug 1004114 but readjust if this is separate. ** Information type changed from Private Security to Public ** Tags added: security ** This bug has been marked a duplicate of bug 1004114 Password logging -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1185905 Title: User tokens logged by keystoneclient.middleware.auth_token Status in OpenStack Identity (Keystone): Triaged Bug description: At level DEBUG, keystoneclient.middleware.auth_token will log user tokens, both when storing to and retrieving from memcache. I would expect that credentials are not logged at any level. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1185905/+subscriptions From fungi at yuggoth.org Thu May 30 19:16:34 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 30 May 2013 19:16:34 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 In-Reply-To: <51A75E9C.3040100@redhat.com> References: <1369922588.2769.160.camel@willson.li.ssimo.org> <51A75E9C.3040100@redhat.com> Message-ID: <20130530191633.GH1472@yuggoth.org> On 2013-05-30 10:13:48 -0400 (-0400), Russell Bryant wrote: > I can't see it either. That's usually because a change is marked as a > DRAFT. Only specific people you add can see a DRAFT. > > A public equivalent status is to mark it as Work-in-progress. Yes, it was apparently uploaded as a draft. In current versions of Gerrit, draft changes are basically broken (they're not private enough to be secret and not public enough to be generally reviewable). I too recommend avoiding the draft feature and just marking changes WIP if you don't want to hassle reviewers with them prematurely. However, on a positive note, I think this is the first SecurityImpact change notification since we added that trigger last fall? It works! -- Jeremy Stanley From Joel.Coffman at jhuapl.edu Thu May 30 19:36:02 2013 From: Joel.Coffman at jhuapl.edu (Coffman, Joel M.) Date: Thu, 30 May 2013 15:36:02 -0400 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 In-Reply-To: <51A75E9C.3040100@redhat.com> References: <1369922588.2769.160.camel@willson.li.ssimo.org> <51A75E9C.3040100@redhat.com> Message-ID: I apologize for the confusion about this particular review. We wanted feedback from just a few other developers before we mark this patch as a work in progress so everyone will have access to it. Cheers, Joel -----Original Message----- From: Russell Bryant [mailto:rbryant at redhat.com] Sent: Thursday, May 30, 2013 10:14 AM To: openstack-security at lists.openstack.org Cc: Coffman, Joel M. Subject: Re: [Openstack-security] [openstack/nova] SecurityImpact review request change I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 On 05/30/2013 10:03 AM, Simo Sorce wrote: > On Thu, 2013-05-30 at 00:00 +0000, gerrit2 at review.openstack.org wrote: >> Hi, I'd like you to take a look at this patch for potential >> SecurityImpact. >> https://review.openstack.org/30973 >> >> Log: >> commit 4501821c9728dcb1f7a741b70537ffa03e3e53a0 >> Author: Joel Coffman >> Date: Wed May 29 19:09:35 2013 -0400 >> >> Create key manager interface >> >> The key manager interface is used by the volume encryption code to retrieve >> keys for volumes. >> >> Implements: blueprint encrypt-cinder-volumes >> Change-Id: I9b0dcb7d648ee6809185c71ba457c8a8a6c90d50 >> SecurityImpact > > Is there a good reason why access to the review is restricted ? > (I can't access it) I can't see it either. That's usually because a change is marked as a DRAFT. Only specific people you add can see a DRAFT. A public equivalent status is to mark it as Work-in-progress. -- Russell Bryant From gerrit2 at review.openstack.org Thu May 30 23:45:57 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 May 2013 23:45:57 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I358813b3ecde4f88de7202c1c07d9b1168c2c332 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/30976 Log: commit 2b5ce748ca38f69d9136abd410369d4671b89de3 Author: Joel Coffman Date: Wed May 29 19:14:56 2013 -0400 Add encryption support for volumes Add support to encrypt Cinder volumes. Modified the libvirt driver to encrypt volumes during the attach call. Created a new VolumeEncryptor class that is responsible for encrypting volumes. The default implementation does not do enryption, and a DmCryptVolumeEncryptor is provided to encrypt volumes using dmcrypt. This feature requires related changes within Cinder (e.g., storing encryption key UUIDs for encrypted volumes), which have not yet been accepted. This patch is fully functional but is will require further modifications (that are relatively minor) once the related Cinder changes have been accepted. Implements: blueprint encrypt-cinder-volumes Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332 SecurityImpact