From 1484237 at bugs.launchpad.net Mon Feb 1 07:05:29 2016 From: 1484237 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 01 Feb 2016 07:05:29 -0000 Subject: [Openstack-security] [Bug 1484237] Change abandoned on keystone (stable/kilo) References: <20150812185544.5991.94491.malonedeb@gac.canonical.com> Message-ID: <20160201070529.31902.36666.malone@wampee.canonical.com> Change abandoned by Steve Martinelli (stevemar at ca.ibm.com) on branch: stable/kilo Review: https://review.openstack.org/222728 Reason: abandoning since it hasn't moved since september -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1484237 Title: token revocations not always respected when using fernet tokens Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) kilo series: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: A simple test that shows that fernet tokens are not always being invalidated. Simple test steps: 1) gets a token 2) deletes a token 3) tries to validate the deleted token When I run this in production on 10 tokens, I get about a 20% success rate on the token being detected as invalid, 80% of the time, keystone tells me the token is valid. I have validated that the token is showing in the revocation event table. I've tried a 5 second delay between the calls which did not change the behavior. My current script (below) will look for 204 and 404 to show failure and will wait forever. I've let it wait over 5 minutes, it seems to me that either keystone knows immediately that the token is invalid or not at all. I do not have memcache enabled on these nodes. The same test has a 100% pass rate with UUID tokens. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1484237/+subscriptions From gerrit2 at review.openstack.org Mon Feb 1 17:57:42 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 01 Feb 2016 17:57:42 +0000 Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact review request change I02054d80f68f38145b399909d60db80a4d91c1ba Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/263972 Log: commit 85bd793fb1368fbcf2c16a4ec6a6af53de70b23b Author: Arun Kant Date: Tue Jan 5 16:37:53 2016 -0800 Adding spec for supporting multiple secret store backends Updated patch to clarify review comments and correct typos. APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From morgan.fainberg at gmail.com Tue Feb 2 20:06:46 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Tue, 02 Feb 2016 20:06:46 -0000 Subject: [Openstack-security] [Bug 1362343] Re: weak digest algorithm for PKI References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20160202200647.25173.37538.malone@soybean.canonical.com> PKI Tokens are Deprecated ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1362343 Title: weak digest algorithm for PKI Status in OpenStack Identity (keystone): Won't Fix Status in python-keystoneclient: Fix Released Bug description: The digest algorithm for PKI tokens is the openssl default of sha1. This is a weak algorithm and some security standards require a stronger algorithm such as sha256. Keystone should make the token digest hash algorithm configurable so that deployments can use a stronger algorithm. Also, the default could be stronger. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362343/+subscriptions From morgan.fainberg at gmail.com Tue Feb 2 20:19:37 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Tue, 02 Feb 2016 20:19:37 -0000 Subject: [Openstack-security] [Bug 1379077] Re: Tenants can be created with invalid ids References: <20141009004653.32578.45865.malonedeb@gac.canonical.com> Message-ID: <20160202201937.15395.13959.malone@gac.canonical.com> With V2 slowly disappearing, i am marking this as Wont Fix. ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1379077 Title: Tenants can be created with invalid ids Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Identity (keystone) icehouse series: Won't Fix Status in OpenStack Identity (keystone) juno series: Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: When creating a new tenant, there is an optional argument 'id' that may be passed: https://github.com/openstack/keystone/blob/9025b64a8f2bf5cf01a18453d6728e081bd2c3b9/keystone/assignment/controllers.py#L114 If not passed, this just creates a uuid and proceeds. If a value is passed, it will use that value. So a user with priv's to create a tenant can pass something like "../../../../../" as the id. If this is done, then the project can't be deleted without manually removing the value from the database. This can lead to a DoS that could fill the db and take down the cloud, in the worst of circumstances. I believe the proper fix here would be to just remove this feature altogether. But this is because I'm not clear about why we would ever want to allow someone to set the id manually. If there's a valid use case here, then we should at least do some input validation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1379077/+subscriptions From morgan.fainberg at gmail.com Tue Feb 2 21:19:05 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Tue, 02 Feb 2016 21:19:05 -0000 Subject: [Openstack-security] [Bug 1534284] Re: keystoneclient should not use etree XML parsing References: <20160114194930.29365.34205.malonedeb@chaenomeles.canonical.com> Message-ID: <20160202211907.12804.24639.launchpad@chaenomeles.canonical.com> ** Changed in: keystoneauth Status: New => Triaged ** Changed in: keystoneauth Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534284 Title: keystoneclient should not use etree XML parsing Status in keystoneauth: Triaged Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: New Bug description: XML parsing is surprisingly difficult and fraught with danger, for example entity expansion makes it easy to cause a lot of memory to be used and therefore crash your system. keystoneclient is using etree parsing which has these potential issues, although in the case of keystoneclient it's the response from the IdP which I think is generally trusted. This is in python- keystoneclient/keystoneclient/contrib/auth/v3/saml2.py There's a defusedxml parser that has protections against these attacks and should therefore be used instead if possible - https://pypi.python.org/pypi/defusedxml - the docs for this page also include some examples of other possible attacks. This was caught by bandit 0.17.0. I'm going to start this out as private security so we can think about it some more before it goes public, even though it's probably not something that needs an issue since I think the source is generally trusted. If you can't trust your IdP then who can you trust? To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534284/+subscriptions From gerrit2 at review.openstack.org Wed Feb 3 15:00:34 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 03 Feb 2016 15:00:34 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ieb03aaba887492819f9c58aa67f7acfcea81720e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/275735 Log: commit 8edaead433eb20574a01c32b6d961d8b4cbfb009 Author: Erno Kuvaja Date: Tue Jan 19 13:37:05 2016 +0000 Prevent user to remove last location of the image If the last location of the image is removed, image transitions back to queued. This allows user to upload new data into the existing image record. By preventing removal of the last location we prevent the image transition back to queued. This change also prevents doing the same operation via replacing the locations with empty list. SecurityImpact DocImpact APIImpact Conflicts: glance/tests/unit/v2/test_images_resource.py Conflicts: glance/api/v2/images.py Change-Id: Ieb03aaba887492819f9c58aa67f7acfcea81720e Closes-Bug: #1525915 (cherry picked from commit e9e45baa9aaf58e69964419b6b4fb2048d115a0c) From gerrit2 at review.openstack.org Wed Feb 3 15:00:42 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 03 Feb 2016 15:00:42 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ieb03aaba887492819f9c58aa67f7acfcea81720e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/275736 Log: commit 6deee085e8f8045633745ba1aabc1779ac5b2a89 Author: Erno Kuvaja Date: Tue Jan 19 13:37:05 2016 +0000 Prevent user to remove last location of the image If the last location of the image is removed, image transitions back to queued. This allows user to upload new data into the existing image record. By preventing removal of the last location we prevent the image transition back to queued. This change also prevents doing the same operation via replacing the locations with empty list. SecurityImpact DocImpact APIImpact Conflicts: glance/tests/unit/v2/test_images_resource.py Change-Id: Ieb03aaba887492819f9c58aa67f7acfcea81720e Closes-Bug: #1525915 (cherry picked from commit e9e45baa9aaf58e69964419b6b4fb2048d115a0c) From gerrit2 at review.openstack.org Wed Feb 3 15:00:49 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 03 Feb 2016 15:00:49 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ieb03aaba887492819f9c58aa67f7acfcea81720e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/275737 Log: commit d2e14fea66466180044f449d5011688227dda616 Author: Erno Kuvaja Date: Tue Jan 19 13:37:05 2016 +0000 Prevent user to remove last location of the image If the last location of the image is removed, image transitions back to queued. This allows user to upload new data into the existing image record. By preventing removal of the last location we prevent the image transition back to queued. This change also prevents doing the same operation via replacing the locations with empty list. SecurityImpact DocImpact APIImpact Change-Id: Ieb03aaba887492819f9c58aa67f7acfcea81720e Closes-Bug: #1525915 From gerrit2 at review.openstack.org Wed Feb 3 20:53:15 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 03 Feb 2016 20:53:15 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ieb03aaba887492819f9c58aa67f7acfcea81720e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/275735 Log: commit 1fd4e04e180eb63a9513db733967234183a6c5a3 Author: Erno Kuvaja Date: Tue Jan 19 13:37:05 2016 +0000 Prevent user to remove last location of the image If the last location of the image is removed, image transitions back to queued. This allows user to upload new data into the existing image record. By preventing removal of the last location we prevent the image transition back to queued. This change also prevents doing the same operation via replacing the locations with empty list. SecurityImpact DocImpact APIImpact Conflicts: glance/tests/unit/v2/test_images_resource.py Conflicts: glance/api/v2/images.py Change-Id: Ieb03aaba887492819f9c58aa67f7acfcea81720e Closes-Bug: #1525915 (cherry picked from commit e9e45baa9aaf58e69964419b6b4fb2048d115a0c) From gerrit2 at review.openstack.org Wed Feb 3 21:52:07 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 03 Feb 2016 21:52:07 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ieb03aaba887492819f9c58aa67f7acfcea81720e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/275737 Log: commit 6179e1e98808548f1c12a2b66784cac3c1e5ac0f Author: Erno Kuvaja Date: Tue Jan 19 13:37:05 2016 +0000 Prevent user to remove last location of the image If the last location of the image is removed, image transitions back to queued. This allows user to upload new data into the existing image record. By preventing removal of the last location we prevent the image transition back to queued. This change also prevents doing the same operation via replacing the locations with empty list. SecurityImpact DocImpact APIImpact Change-Id: Ieb03aaba887492819f9c58aa67f7acfcea81720e Closes-Bug: #1525915 From gerrit2 at review.openstack.org Thu Feb 4 00:29:29 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 04 Feb 2016 00:29:29 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ieb03aaba887492819f9c58aa67f7acfcea81720e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/275735 Log: commit 819f93f6b60ad92e0469a595553e1b75f8971209 Author: Erno Kuvaja Date: Tue Jan 19 13:37:05 2016 +0000 Prevent user to remove last location of the image If the last location of the image is removed, image transitions back to queued. This allows user to upload new data into the existing image record. By preventing removal of the last location we prevent the image transition back to queued. This change also prevents doing the same operation via replacing the locations with empty list. SecurityImpact DocImpact APIImpact Conflicts: glance/tests/unit/v2/test_images_resource.py Conflicts: glance/api/v2/images.py Change-Id: Ieb03aaba887492819f9c58aa67f7acfcea81720e Closes-Bug: #1525915 (cherry picked from commit e9e45baa9aaf58e69964419b6b4fb2048d115a0c) From tony at bakeyournoodle.com Fri Feb 5 00:07:16 2016 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 05 Feb 2016 00:07:16 -0000 Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for OSSA-2015-005 References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com> Message-ID: <20160205000716.15839.26648.malone@gac.canonical.com> So I'm not certain this represents a security issue. From comment 2: 1. start a localhost web server with python 2. create a index.html file for localhost which has a With this in place yes I can visit http://localhost/ and get a VNC console in my instance but this differs from the original bug in several ways 1. I can't find a way to read the token/cookie in my browser and have it populate across domains 2. The upgrade from http:// -> ws:// is all happening within the infrastructure of the (albeit small) cloud. and therefore is valid as far as the Origin: Header is concerned. If we can do either 1. host vnc_auto.html on localhost, and stull get access to the console ; or 2. Read the token/cookie from the browser from a domain NOT associated with $MY_CLOUD Then I agree we have an issue. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1511541 Title: Possible incomplete fix for OSSA-2015-005 Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Incomplete Bug description: Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete. https://bugs.launchpad.net/nova/+bug/1409142/comments/146 https://bugs.launchpad.net/nova/+bug/1409142/comments/149 Further investigation is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1511541/+subscriptions From 1511541 at bugs.launchpad.net Fri Feb 5 04:26:17 2016 From: 1511541 at bugs.launchpad.net (Augustina Ragwitz) Date: Fri, 05 Feb 2016 04:26:17 -0000 Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for OSSA-2015-005 References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com> Message-ID: <20160205042619.12398.30781.launchpad@chaenomeles.canonical.com> ** Changed in: nova Status: New => Confirmed ** Changed in: nova Status: Confirmed => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1511541 Title: Possible incomplete fix for OSSA-2015-005 Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Incomplete Bug description: Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete. https://bugs.launchpad.net/nova/+bug/1409142/comments/146 https://bugs.launchpad.net/nova/+bug/1409142/comments/149 Further investigation is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1511541/+subscriptions From 1450798 at bugs.launchpad.net Fri Feb 5 14:20:42 2016 From: 1450798 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 05 Feb 2016 14:20:42 -0000 Subject: [Openstack-security] [Bug 1450798] Re: Multiple command injection vulns in schema_diff tool References: <20150501135051.16168.63595.malonedeb@gac.canonical.com> Message-ID: <20160205142042.24801.99075.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/276751 ** Changed in: nova Assignee: Roman Podoliaka (rpodolyaka) => stgleb (gstepanov) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1450798 Title: Multiple command injection vulns in schema_diff tool Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: These lines in the latest Nova (as of May 1, 2015) are vulnerable to command injection https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117 In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 ), if a malicious filename such as "; rm -rf /etc" is provided, the /etc directory will be removed with the privileges of the user running this script. In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. In this case(https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. I'm not familiar enough with the usage of this module to know all of the places these inputs can come from, but presumably it can be used in automation, potentially with elevated privileges. I'm sure the idea of this script is to allow certain functionality, not unrestricted commands. The way this has been developed allows unrestricted command execution by tampering with any of the above mentioned inputs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1450798/+subscriptions From dmccowan at cisco.com Fri Feb 5 16:47:57 2016 From: dmccowan at cisco.com (Dave McCowan) Date: Fri, 05 Feb 2016 16:47:57 -0000 Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for OSSA-2015-005 References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com> Message-ID: <20160205164757.12548.88757.malone@chaenomeles.canonical.com> @tony, correct. The procedure in step 2 does not recreate the original bug. By putting the link to src=http://$MY_CLOUD_IP:6080/vnc_auto.html?token=$INSTANCE_TOKEN> in the frame, the VNC code will be loaded from $MY_CLOUD and the origin header will show $MY_CLOUD. To recreate the bug, you need to install the VNC package on your local host (or another host), and then link to http://localhost/noVNC/vnc.html. After entering $MY_CLOUD_IP in the served console page, a request will be made from the browser to $MY_CLOUD. This request will be GET $MY_CLOUD_IP/websockify. The origin header on this request will be null, indicating the script came from the local host. The origin header will show $MY_CLOUD_IP on an acceptable request. It will show attacker.example.com on a truly malicious request. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1511541 Title: Possible incomplete fix for OSSA-2015-005 Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Incomplete Bug description: Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete. https://bugs.launchpad.net/nova/+bug/1409142/comments/146 https://bugs.launchpad.net/nova/+bug/1409142/comments/149 Further investigation is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1511541/+subscriptions From gerrit2 at review.openstack.org Sat Feb 6 12:24:34 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 06 Feb 2016 12:24:34 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ieb03aaba887492819f9c58aa67f7acfcea81720e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/275735 Log: commit c5c731c7153d6d46c27260474d2811d504dfac5c Author: Erno Kuvaja Date: Tue Jan 19 13:37:05 2016 +0000 Prevent user to remove last location of the image If the last location of the image is removed, image transitions back to queued. This allows user to upload new data into the existing image record. By preventing removal of the last location we prevent the image transition back to queued. This change also prevents doing the same operation via replacing the locations with empty list. SecurityImpact DocImpact APIImpact Conflicts: glance/tests/unit/v2/test_images_resource.py Conflicts: glance/api/v2/images.py Change-Id: Ieb03aaba887492819f9c58aa67f7acfcea81720e Closes-Bug: #1525915 (cherry picked from commit e9e45baa9aaf58e69964419b6b4fb2048d115a0c) From gerrit2 at review.openstack.org Sat Feb 6 18:17:32 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 06 Feb 2016 18:17:32 +0000 Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact review request change I02054d80f68f38145b399909d60db80a4d91c1ba Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/263972 Log: commit a4174b7746ad3e8fd16bf2fa443294ab23785882 Author: Arun Kant Date: Tue Jan 5 16:37:53 2016 -0800 Adding spec for supporting multiple secret store backends Updated patch to clarify review comments and correct typos. APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From morgan.fainberg at gmail.com Mon Feb 8 10:25:02 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Mon, 08 Feb 2016 10:25:02 -0000 Subject: [Openstack-security] [Bug 1543048] [NEW] support alternative password hashing in keystone Message-ID: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Public bug reported: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg ** Affects: keystone Importance: Wishlist Status: New ** Tags: password security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): New Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From morgan.fainberg at gmail.com Mon Feb 8 10:25:46 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Mon, 08 Feb 2016 10:25:46 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <20160208102546.31439.65076.malone@wampee.canonical.com> Set this as wishlist as it would be at best a nice-to-have. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): New Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From morgan.fainberg at gmail.com Mon Feb 8 10:28:34 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Mon, 08 Feb 2016 10:28:34 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <20160208102835.31244.99902.malone@wampee.canonical.com> I would have included scrypt support as a "nice to have" as part of the proposal as well, but passlib does not currently implement scrypt and I expect we should maintain a single library for password hashing for code maintenance/supportability reasons. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): New Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From fungi at yuggoth.org Mon Feb 8 20:03:12 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 08 Feb 2016 20:03:12 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <20160208200312.15629.18272.malone@gac.canonical.com> There's nothing wrong with using SHA-2/512, AS LONG as you use it in a key derivation function (you really just shouldn't use the bare hashing algorithm to secure keys/passwords). I've been going with passlib's pbkdf2_sha512 scheme to great satisfaction in another (non-OpenStack) project, and recommend it highly. Something like: passlib.context.CryptContext(all__vary_rounds=0.1, default="pbkdf2_sha512", pbkdf2_sha512__default_rounds=1000, schemes=["pbkdf2_sha512"]) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): New Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From 1484237 at bugs.launchpad.net Tue Feb 9 00:33:47 2016 From: 1484237 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 09 Feb 2016 00:33:47 -0000 Subject: [Openstack-security] [Bug 1484237] Change abandoned on keystone (master) References: <20150812185544.5991.94491.malonedeb@gac.canonical.com> Message-ID: <20160209003347.31244.78043.malone@wampee.canonical.com> Change abandoned by Steve Martinelli (stevemar at ca.ibm.com) on branch: master Review: https://review.openstack.org/220259 Reason: no change in >3 months, and the original bug is now fixed in liberty, closing this change up -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1484237 Title: token revocations not always respected when using fernet tokens Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) kilo series: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: A simple test that shows that fernet tokens are not always being invalidated. Simple test steps: 1) gets a token 2) deletes a token 3) tries to validate the deleted token When I run this in production on 10 tokens, I get about a 20% success rate on the token being detected as invalid, 80% of the time, keystone tells me the token is valid. I have validated that the token is showing in the revocation event table. I've tried a 5 second delay between the calls which did not change the behavior. My current script (below) will look for 204 and 404 to show failure and will wait forever. I've let it wait over 5 minutes, it seems to me that either keystone knows immediately that the token is invalid or not at all. I do not have memcache enabled on these nodes. The same test has a 100% pass rate with UUID tokens. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1484237/+subscriptions From 1532317 at bugs.launchpad.net Tue Feb 9 12:13:06 2016 From: 1532317 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 09 Feb 2016 12:13:06 -0000 Subject: [Openstack-security] [Bug 1532317] Re: Only ingress rules are supported in security groups References: <20160108202404.8643.13925.malonedeb@wampee.canonical.com> Message-ID: <20160209121306.15526.20720.malone@gac.canonical.com> Reviewed: https://review.openstack.org/271972 Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=ec5a5af3df1c046618f15d71e7d60db43ddb90f9 Submitter: Jenkins Branch: stable/kilo commit ec5a5af3df1c046618f15d71e7d60db43ddb90f9 Author: Dmytro Dovbii Date: Tue Jan 19 11:36:37 2016 +0200 [Core-Library] Add ability to specify direction and ethetype for groups Previously there was no way to specify in which direction security rule should be applied, only ingress was supported. Also it was impossible to create IPv6 rules. This patch added ability to specify direction and ethertype for Neutron security groups and direction - for AWS security groups Change-Id: Iba5be7a8a94c34eab3e0e06f95e5358a84a5dd7b Closes-Bug: #1532317 (cherry picked from commit 186612daf708b0ad3199bbf77ea8d3ed0f5eb48e) ** Tags added: in-stable-kilo -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1532317 Title: Only ingress rules are supported in security groups Status in Murano: Fix Released Status in Murano kilo series: Fix Released Status in Murano liberty series: Fix Released Status in Murano mitaka series: Fix Released Bug description: There is no way to specify in which direction security rule should be applied, only ingress is supported. Also there should be an optional key in existing parameter specifying rule IP protocol version (IPv4/IPv6) https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/system/NeutronSecurityGroupManager.yaml#L56 https://github.com/openstack/heat/blob/stable/kilo/heat/engine/resources/openstack/neutron/security_group.py#L50 To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1532317/+subscriptions From travis.mcpeak at hpe.com Tue Feb 9 14:51:47 2016 From: travis.mcpeak at hpe.com (Travis McPeak) Date: Tue, 09 Feb 2016 14:51:47 -0000 Subject: [Openstack-security] [Bug 1450798] Re: Multiple command injection vulns in schema_diff tool References: <20150501135051.16168.63595.malonedeb@gac.canonical.com> Message-ID: <20160209145147.24340.63262.malone@soybean.canonical.com> Hmm, ok. It's still being called with shell=True needlessly, as there are documented safe ways of doing what you're trying to do here: https://security.openstack.org/guidelines/dg_avoid-shell-true.html . Is it possible that it will be used as part of an automated process that takes input from somewhere that might be user controlled? If so this can lead to code being run on that box. If nothing else when poor examples like this begin to make their way out of the code at least new developers won't copy these patterns to places that are more mission critical. That being said, if the idea is that "it isn't run in production so we don't care", I'll certainly file with that in mind in the future. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1450798 Title: Multiple command injection vulns in schema_diff tool Status in OpenStack Compute (nova): Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: These lines in the latest Nova (as of May 1, 2015) are vulnerable to command injection https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117 In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 ), if a malicious filename such as "; rm -rf /etc" is provided, the /etc directory will be removed with the privileges of the user running this script. In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. In this case(https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. I'm not familiar enough with the usage of this module to know all of the places these inputs can come from, but presumably it can be used in automation, potentially with elevated privileges. I'm sure the idea of this script is to allow certain functionality, not unrestricted commands. The way this has been developed allows unrestricted command execution by tampering with any of the above mentioned inputs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1450798/+subscriptions From 1355509 at bugs.launchpad.net Fri Feb 12 17:05:07 2016 From: 1355509 at bugs.launchpad.net (Vitaly Sedelnik) Date: Fri, 12 Feb 2016 17:05:07 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20160212170507.8052.26642.launchpad@wampee.canonical.com> ** Tags added: wontfix-feature -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355509 Title: Better conductor deployment Status in Fuel for OpenStack: Won't Fix Status in Fuel for OpenStack 6.0.x series: Won't Fix Status in Fuel for OpenStack 7.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From doug at doughellmann.com Wed Feb 17 18:06:58 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 17 Feb 2016 18:06:58 -0000 Subject: [Openstack-security] [Bug 1534299] Fix included in openstack/keystoneauth 2.3.0 References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com> Message-ID: <20160217180658.528.42873.malone@gac.canonical.com> This issue was fixed in the openstack/keystoneauth 2.3.0 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534299 Title: keystoneclient needs to mark secret config options Status in keystoneauth: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Fix Released Bug description: oslo_config allows marking config options such as password as "secret", such that when/if the config options are logged they're masked out of the logs. keystoneclient defines several options for auth plugins that should be secret but are not, such as the user's password in the identity, oidc, and saml2 plugins. I don't know if these really need to be private security but might as well start out that way. To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534299/+subscriptions From doug at doughellmann.com Wed Feb 17 18:11:50 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 17 Feb 2016 18:11:50 -0000 Subject: [Openstack-security] [Bug 1534299] Fix included in openstack/python-keystoneclient 2.2.0 References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com> Message-ID: <20160217181150.24749.74289.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/python-keystoneclient 2.2.0 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534299 Title: keystoneclient needs to mark secret config options Status in keystoneauth: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Fix Released Bug description: oslo_config allows marking config options such as password as "secret", such that when/if the config options are logged they're masked out of the logs. keystoneclient defines several options for auth plugins that should be secret but are not, such as the user's password in the identity, oidc, and saml2 plugins. I don't know if these really need to be private security but might as well start out that way. To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534299/+subscriptions From stevemar at ca.ibm.com Mon Feb 22 06:13:50 2016 From: stevemar at ca.ibm.com (Steve Martinelli) Date: Mon, 22 Feb 2016 06:13:50 -0000 Subject: [Openstack-security] [Bug 1268751] Re: Potential token revocation abuse via group membership References: <20140113215431.25014.35474.malonedeb@chaenomeles.canonical.com> Message-ID: <20160222061352.1515.85183.launchpad@soybean.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1268751 Title: Potential token revocation abuse via group membership Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a group is deleted, all tokens for all users that are a member of that group are revoked. This leads to potential abuse: 1. A group admin adds a user to a group without users knowledge 2. User creates token 3. Admin deletes group. 4. All of the users tokens are revoked. Admittedly, this abuse must be instigated by a group admin, which is the global admin in the default policy file, but an alternative policy file could allow for the delegation of "add user to group" behavior. In such a system, this could act as a denial of service attack for a set of users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1268751/+subscriptions From stevemar at ca.ibm.com Mon Feb 22 06:51:13 2016 From: stevemar at ca.ibm.com (Steve Martinelli) Date: Mon, 22 Feb 2016 06:51:13 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <20160222065113.1571.88228.malone@chaenomeles.canonical.com> Marking bug 1176134 as a dupe of this bug, since this bug as more detail. I'll add the description here: ===== 1176134: Password handling should be pluggable As of now in sql backend, password handling code is embedded in identity driver. (ie), number of iteration, how the hash value is calculated, salt value etc. Ideally it should be pluggable with the current code be the default implementation ===== -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): New Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From 1455582 at bugs.launchpad.net Tue Feb 23 15:00:22 2016 From: 1455582 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 23 Feb 2016 15:00:22 -0000 Subject: [Openstack-security] [Bug 1455582] Re: Hypervisor compromise may result in malicious trust creation References: <20150515171809.26411.43467.malonedeb@gac.canonical.com> Message-ID: <20160223150022.1606.60774.malone@chaenomeles.canonical.com> Closing this because bearer tokens, etc, are a well known weakness. ** Changed in: keystone Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1455582 Title: Hypervisor compromise may result in malicious trust creation Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a hypervisor is compromised, and the hypervisor is a a Nova compute node, the end user now has access to every token that passes through that node. By default, a keystone token can be exchanged for another token. There is no restriction on scoping of the new token. A scoped token can be exchanged for an unscoped token, or a token scoped to a different project. We had set the default time limit for tokens down to 1 hour, to reduce the surface area of the attack. However, many workloads require a single token for the whole workload, and these workloads take more than one hour, so several installations have increased token lifespans back to the old value of 24 hours. A token can be used to change a password. If this is done, all tokens are revoked for the user. With the trust API, a user can set up a long term delegation that allows another user to perform an operation on their behalf. While tokens created via trusts are limited in what they can do, the limitations are only on things like change passwords or create a new token. Thus, if an attacker compromises a compute node and harvests tokens, the highest value attack for them is to automatically create a trust from the compromised user to some other account. This bypasses the time limitation of the token expiration, and will allow the attacker to perform operations on the users resources at the attackers convenience. Any site that is running a recent version of Heat would be expected to have many trusts set up from the customer user accounts to the Heat service user. Heat creates trusts using the users tokens, so we know this approach is not just theoretical, but actively used. This leaves a fairly obvious trail, in that a user can see all of the trusts created with the user as the trustor. Any trusts that do not have a Heat user as the trustee are suspect. It might even be possible to compromise Heat users, so even those should be audited. There are other ways that a harvested token can be abused, but the trust approach is the one I find the most worrysome, as it could be done as a "sleeper" agent. The same issues apply to the OAUTH1.0a extension. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions From run2obtain at gmail.com Wed Feb 24 13:30:04 2016 From: run2obtain at gmail.com (Kenny Aondona) Date: Wed, 24 Feb 2016 13:30:04 +0000 Subject: [Openstack-security] Openstack-security Digest, Vol 36, Issue 14 In-Reply-To: References: Message-ID: Hi everyone, I was just wondering about this and thought it wise to ask. Asides this list, is there a way to pull openstack security bugs and advisories/reports programmatically maybe in json format ? This feature could be useful for security automation etc. Thanks, Ken On Wed, Feb 24, 2016, 13:01 wrote: > Send Openstack-security mailing list submissions to > openstack-security at lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > or, via email, send a message with subject or body 'help' to > openstack-security-request at lists.openstack.org > > You can reach the person managing the list at > openstack-security-owner at lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Openstack-security digest..." > > > Today's Topics: > > 1. [Bug 1455582] Re: Hypervisor compromise may result in > malicious trust creation (Dolph Mathews) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Feb 2016 15:00:22 -0000 > From: Dolph Mathews <1455582 at bugs.launchpad.net> > To: openstack-security at lists.openstack.org > Subject: [Openstack-security] [Bug 1455582] Re: Hypervisor compromise > may result in malicious trust creation > Message-ID: > <20160223150022.1606.60774.malone at chaenomeles.canonical.com> > Content-Type: text/plain; charset="utf-8" > > Closing this because bearer tokens, etc, are a well known weakness. > > ** Changed in: keystone > Status: Confirmed => Won't Fix > > -- > You received this bug notification because you are a member of OpenStack > Security, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1455582 > > Title: > Hypervisor compromise may result in malicious trust creation > > Status in OpenStack Identity (keystone): > Won't Fix > Status in OpenStack Security Advisory: > Won't Fix > Status in OpenStack Security Notes: > Fix Released > > Bug description: > > If a hypervisor is compromised, and the hypervisor is a a Nova compute > node, the end user now has access to every token that passes through that > node. > > By default, a keystone token can be exchanged for another token. There > is no restriction on scoping of the new token. A scoped token can be > exchanged for an unscoped token, or a token scoped to a different > project. > > We had set the default time limit for tokens down to 1 hour, to reduce > the surface area of the attack. However, many workloads require a > single token for the whole workload, and these workloads take more > than one hour, so several installations have increased token lifespans > back to the old value of 24 hours. > > A token can be used to change a password. If this is done, all tokens > are revoked for the user. > > With the trust API, a user can set up a long term delegation that > allows another user to perform an operation on their behalf. While > tokens created via trusts are limited in what they can do, the > limitations are only on things like change passwords or create a new > token. > > Thus, if an attacker compromises a compute node and harvests tokens, > the highest value attack for them is to automatically create a trust > from the compromised user to some other account. This bypasses the > time limitation of the token expiration, and will allow the attacker > to perform operations on the users resources at the attackers > convenience. > > Any site that is running a recent version of Heat would be expected to > have many trusts set up from the customer user accounts to the Heat > service user. Heat creates trusts using the users tokens, so we know > this approach is not just theoretical, but actively used. > > This leaves a fairly obvious trail, in that a user can see all of the > trusts created with the user as the trustor. Any trusts that do not > have a Heat user as the trustee are suspect. It might even be > possible to compromise Heat users, so even those should be audited. > > There are other ways that a harvested token can be abused, but the > trust approach is the one I find the most worrysome, as it could be > done as a "sleeper" agent. > > The same issues apply to the OAUTH1.0a extension. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions > > > > ------------------------------ > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > End of Openstack-security Digest, Vol 36, Issue 14 > ************************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1436082 at bugs.launchpad.net Wed Feb 24 16:37:05 2016 From: 1436082 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 24 Feb 2016 16:37:05 -0000 Subject: [Openstack-security] [Bug 1436082] Fix merged to glance_store (master) References: <20150324214535.8217.99560.malonedeb@soybean.canonical.com> Message-ID: <20160224163705.1547.67041.malone@gac.canonical.com> Reviewed: https://review.openstack.org/168507 Committed: https://git.openstack.org/cgit/openstack/glance_store/commit/?id=2572ea1410d4cb02b65f5791681d4d8e54adc67c Submitter: Jenkins Branch: master commit 2572ea1410d4cb02b65f5791681d4d8e54adc67c Author: Ian Cordasco Date: Fri Mar 27 17:49:36 2015 -0500 Switch HTTP store to using requests Previously the HTTP store was using httplib and specifically unverified HTTPS connections to download data about images. By switching to using requests, we will get several benefits: 1. Certificate verification when using HTTPS 2. Connection pooling when following redirects 3. Help handling redirects Closes-bug: 1263067 Partial-bug: 1436082 Implements: blueprint http-store-on-requests Co-Authored-By: Sabari Kumar Murugesan Change-Id: Ib114919c1e1361ba64fe9e8382e1a2c39dbb3271 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1436082 Title: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection Status in glance_store: In Progress Status in OpenStack Security Notes: Fix Released Bug description: VMWare store: https://github.com/openstack/glance_store/blob/ea88e503b617a7ac9a0ae7e537d6517e9992a104/glance_store/_drivers/vmware_datastore.py#L501 (_get_conn_class above uses simply httplib.HTTPSConnection). HTTP Store: https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/http.py#L179 This leaves both stores open to man-in-the-middle attacks while transferring image data. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1436082/+subscriptions From fungi at yuggoth.org Fri Feb 26 03:11:33 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 26 Feb 2016 03:11:33 -0000 Subject: [Openstack-security] [Bug 1550023] Re: Really bad workflow bug in top of tree References: <20160225222542.1668.38501.malonedeb@gac.canonical.com> Message-ID: <20160226031133.1850.65087.malone@soybean.canonical.com> Switched from public security to public and added the security bug tag to indicate this is perhaps hardening or security feature related but not an apparent security vulnerability. ** Information type changed from Public Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550023 Title: Really bad workflow bug in top of tree Status in OpenStack Dashboard (Horizon): In Progress Bug description: The associate floating ip success now takes you to a completely different web page than you started. This is a fundamentally flawed, broken, bad assumption. Ref: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py#L148 It was probably done with the idea that you might want to change/check your sec group after the fact but since it's already too late now, don't do that.... ALso, really breaks the stream of consciousness of working in instances.... Marked as a security vulnerability as the intent here (and it fails badly) is to add or reinforce security. It does nothing of the sort. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1550023/+subscriptions From 1516031 at bugs.launchpad.net Fri Feb 26 03:55:54 2016 From: 1516031 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 03:55:54 -0000 Subject: [Openstack-security] [Bug 1516031] Re: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234) References: <20151113142716.4469.80964.malonedeb@gac.canonical.com> Message-ID: <20160226035554.2014.10381.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/283708 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=4f41717204dea123fac1050956cd87dea261794e Submitter: Jenkins Branch: stable/liberty commit 4f41717204dea123fac1050956cd87dea261794e Author: Brianna Poulos Date: Fri Jan 22 15:13:35 2016 -0500 Remove unneeded glance unit test assert calls The glance_store library now accepts a verifier object for use with verifying signatures, as a result of a recently merged patch [1]. There are some glance unit tests that do not expect this verifier object to be passed to the add method of glance_store, and will therefore fail with a new release of the glance_store library. This patch removes the assert lines for the tests that will fail, since it is not necessary for glance to test glance_store in that way at the glance level. [1] https://review.openstack.org/#/c/183110/ Change-Id: I404fbc40dafa159a63a6dfee563f05ee80c073dc Partial-Bug: #1516031 (cherry picked from commit eab1567d48a18fa968c7b66c3641dd037da1f84e) -- squashed with another change to get liberty working -- Remove glance_store specific unit tests TestStoreAddToBackend contains a set of tests that should belong to the glance_store. Recently, these tests were about to break glance as they mocked internal methods. Those mocks were removed in commit eab1567d48a18fa968c7b66c3641dd037da1f84e. The tests are added back to glance_store in change https://review.openstack.org/#/c/273786. Conflicts: glance/tests/unit/test_store_image.py Closes-Bug: #1548902 Depends-On: I688629d37e9146aef33fbc9bb6fd8780521e06ab Change-Id: Ic67826a4d02cb30cc429a3d4abc46d6ca96f31ad (cherry picked from commit 1ebbfd3dc1694dc4f26e763da9eee833bb5d2545) ** Tags added: in-stable-liberty -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1516031 Title: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234) Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: This have been reported by Daniel P. Berrange: " In the OpenStack Liberty release, the Glance project added support for image signature verification. http://specs.openstack.org/openstack/glance-specs/specs/liberty/image- signing-and-verification-support.html The verification code was added in the following git commit https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e Unfortunately the design of this signature verification method is flawed by design. The generalized approach to creating signatures of content is to apply a hash to the content and then encrypt it in some manner. Consider that the signature is defined to use hash=sha256 and cipher=rsa we can describe the signature computation as signature = rsa(sha256(content)) In the case of verifying a disk image, the content we care about verifying is the complete disk image file. Unfortunately, the glance specification chose *not* to compute the signature against the disk image file. Glance already had an MD5 checksum calculated for the disk image file, so they instead chose to compute the signature against the MD5 checksum instead. ie glance is running signature = rsa(sha256(md5(disk-image-content))) This degrades the security of the system to that of the weakest hash, which is obviously MD5 here. The code where glance verifies the signature is in the glance/locations.py, the 'set_data' method where is does result = signature_utils.verify_signature( self.context, checksum, self.image.extra_properties) if result: LOG.info(_LI("Successfully verified signature for image %s"), self.image.image_id) The 'checksum' variable is populate by the glance_store driver, but it is hardcoded to always be md5 in all current glance storage backends: $ git grep hashlib glance_store/_drivers/ | grep checksum glance_store/_drivers/filesystem.py: checksum = hashlib.md5() glance_store/_drivers/rbd.py: checksum = hashlib.md5() glance_store/_drivers/s3.py: checksum = hashlib.md5() glance_store/_drivers/s3.py: checksum = hashlib.md5() glance_store/_drivers/sheepdog.py: checksum = hashlib.md5() glance_store/_drivers/swift/store.py: checksum = hashlib.md5() glance_store/_drivers/vmware_datastore.py: self.checksum = hashlib.md5() Since we will soon be shipping OpenStack Liberty release, we need to at least give a security notice to alert our customers to the fact that the signature verification is cryptographically weak/broken. IMHO, it quite likely deserves a CVE though NB, this is public knowledge as I first became aware of this flawed design in comments / discussion on a public specification proposed to implement the same approach in the Nova project. My suggested way to fix this is to simply abandon the current impl and re-do it such that it directly computes the signature against the disk image, and does not use the existing md5 checksum in any way. Regards, Daniel " Mailing list thread for Nova impl: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html Nova Spec: https://review.openstack.org/#/c/188874/ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1516031/+subscriptions From 1550330 at bugs.launchpad.net Fri Feb 26 12:54:01 2016 From: 1550330 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 12:54:01 -0000 Subject: [Openstack-security] [Bug 1550330] Re: Elasticsearch plugin fails to build - ca-certificates package update References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160226125401.1847.28253.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/285279 ** Changed in: lma-toolchain Status: Confirmed => In Progress ** Changed in: lma-toolchain Assignee: (unassigned) => Swann Croiset (swann-w) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: In Progress Status in LMA Toolchain 0.8 series: New Status in LMA Toolchain 0.9 series: New Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From 1550330 at bugs.launchpad.net Fri Feb 26 13:02:58 2016 From: 1550330 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 13:02:58 -0000 Subject: [Openstack-security] [Bug 1550330] Re: Elasticsearch plugin fails to build - ca-certificates package update References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160226130259.2286.23562.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/285279 Committed: https://git.openstack.org/cgit/openstack/fuel-plugin-elasticsearch-kibana/commit/?id=1e953897c17e97f77968709d95e517e7f8e610d0 Submitter: Jenkins Branch: master commit 1e953897c17e97f77968709d95e517e7f8e610d0 Author: Swann Croiset Date: Fri Feb 26 13:53:34 2016 +0100 Update ca-certificates package Fixes-bug: #1550330 Change-Id: I9ff5eee39266f7a3d908a1e04b3b798055500655 ** Changed in: lma-toolchain Status: In Progress => Fix Committed ** Changed in: lma-toolchain/0.9 Status: New => In Progress ** Changed in: lma-toolchain/0.9 Assignee: (unassigned) => Swann Croiset (swann-w) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: Fix Committed Status in LMA Toolchain 0.8 series: In Progress Status in LMA Toolchain 0.9 series: In Progress Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From 1550330 at bugs.launchpad.net Fri Feb 26 13:04:11 2016 From: 1550330 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 13:04:11 -0000 Subject: [Openstack-security] [Bug 1550330] Fix proposed to fuel-plugin-elasticsearch-kibana (stable/0.9) References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160226130411.2415.8457.malone@soybean.canonical.com> Fix proposed to branch: stable/0.9 Review: https://review.openstack.org/285286 ** Changed in: lma-toolchain/0.8 Status: New => In Progress ** Changed in: lma-toolchain/0.8 Assignee: (unassigned) => Swann Croiset (swann-w) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: Fix Committed Status in LMA Toolchain 0.8 series: In Progress Status in LMA Toolchain 0.9 series: In Progress Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From 1550330 at bugs.launchpad.net Fri Feb 26 13:04:25 2016 From: 1550330 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 13:04:25 -0000 Subject: [Openstack-security] [Bug 1550330] Fix proposed to fuel-plugin-elasticsearch-kibana (stable/0.8) References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160226130425.1938.19566.malone@soybean.canonical.com> Fix proposed to branch: stable/0.8 Review: https://review.openstack.org/285287 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: Fix Committed Status in LMA Toolchain 0.8 series: In Progress Status in LMA Toolchain 0.9 series: In Progress Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From 1550330 at bugs.launchpad.net Fri Feb 26 13:12:35 2016 From: 1550330 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 13:12:35 -0000 Subject: [Openstack-security] [Bug 1550330] Re: Elasticsearch plugin fails to build - ca-certificates package update References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160226131236.1925.12297.malone@gac.canonical.com> Reviewed: https://review.openstack.org/285287 Committed: https://git.openstack.org/cgit/openstack/fuel-plugin-elasticsearch-kibana/commit/?id=2936059e762ebd75a4f4555ee3eb4c16b91f5d5f Submitter: Jenkins Branch: stable/0.8 commit 2936059e762ebd75a4f4555ee3eb4c16b91f5d5f Author: Swann Croiset Date: Fri Feb 26 13:53:34 2016 +0100 Update ca-certificates package Fixes-bug: #1550330 Change-Id: I9ff5eee39266f7a3d908a1e04b3b798055500655 (cherry picked from commit 1e953897c17e97f77968709d95e517e7f8e610d0) ** Changed in: lma-toolchain/0.8 Status: In Progress => Fix Committed ** Changed in: lma-toolchain/0.9 Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: Fix Committed Status in LMA Toolchain 0.8 series: Fix Committed Status in LMA Toolchain 0.9 series: Fix Committed Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From 1550330 at bugs.launchpad.net Fri Feb 26 13:12:44 2016 From: 1550330 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 13:12:44 -0000 Subject: [Openstack-security] [Bug 1550330] Fix merged to fuel-plugin-elasticsearch-kibana (stable/0.9) References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160226131244.2202.64363.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/285286 Committed: https://git.openstack.org/cgit/openstack/fuel-plugin-elasticsearch-kibana/commit/?id=ed2d063bb19591c2a092ea1a0ef736b6b5a47178 Submitter: Jenkins Branch: stable/0.9 commit ed2d063bb19591c2a092ea1a0ef736b6b5a47178 Author: Swann Croiset Date: Fri Feb 26 13:53:34 2016 +0100 Update ca-certificates package Fixes-bug: #1550330 Change-Id: I9ff5eee39266f7a3d908a1e04b3b798055500655 (cherry picked from commit 1e953897c17e97f77968709d95e517e7f8e610d0) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: Fix Committed Status in LMA Toolchain 0.8 series: Fix Committed Status in LMA Toolchain 0.9 series: Fix Committed Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From 1436082 at bugs.launchpad.net Fri Feb 26 13:37:27 2016 From: 1436082 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Feb 2016 13:37:27 -0000 Subject: [Openstack-security] [Bug 1436082] Fix merged to glance_store (master) References: <20150324214535.8217.99560.malonedeb@soybean.canonical.com> Message-ID: <20160226133727.2146.53246.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/168540 Committed: https://git.openstack.org/cgit/openstack/glance_store/commit/?id=91636e8b85de680ea1347b60b1c2a27022c0f26f Submitter: Jenkins Branch: master commit 91636e8b85de680ea1347b60b1c2a27022c0f26f Author: Ian Cordasco Date: Fri Mar 27 21:18:42 2015 -0500 Switch VMWare Datastore to use Requests Previously the VMWare Datastore was using HTTPS Connections from httplib which do not verify the connection. Switching to requests allows the store to perform proper connection level verification for a secure connection. By switching to using requests, we will get several benefits: 1. Certificate verification when using HTTPS 2. Connection pooling when following redirects 3. Help handling redirects 4. Help with Chunked Encoding Partial-bug: 1436082 Co-authored-by: Sabari Kumar Murugesan Change-Id: I8ff20b2f6bd0e05cd50e44a60ec89fd54f87e1b4 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1436082 Title: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection Status in glance_store: In Progress Status in OpenStack Security Notes: Fix Released Bug description: VMWare store: https://github.com/openstack/glance_store/blob/ea88e503b617a7ac9a0ae7e537d6517e9992a104/glance_store/_drivers/vmware_datastore.py#L501 (_get_conn_class above uses simply httplib.HTTPSConnection). HTTP Store: https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/http.py#L179 This leaves both stores open to man-in-the-middle attacks while transferring image data. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1436082/+subscriptions From tdecacqu at redhat.com Fri Feb 26 18:50:55 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Fri, 26 Feb 2016 18:50:55 -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: <20160226185055.1966.45427.malone@gac.canonical.com> Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. I agree with Robert, this expose OpenStack user instance data to all context running on the compute node. Shell users aside, I fail to see why would apache or even the nobody user be allowed to list and read disk files. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, 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): Opinion Status in OpenStack Security Advisory: Incomplete 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 tdecacqu at redhat.com Mon Feb 29 15:19:15 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 29 Feb 2016 15:19:15 -0000 Subject: [Openstack-security] [Bug 1549547] Re: LBaaS leaking password in logs References: <20160225002843.1623.41446.malonedeb@wampee.canonical.com> Message-ID: <20160229151916.1549.73061.launchpad@wampee.canonical.com> ** Changed in: ossa Status: Incomplete => Won't Fix ** Summary changed: - LBaaS leaking password in logs + LBaaS leaking password in DEBUG logs ** Information type changed from Private Security to Public ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - Current code leaks the keystone admin_password in the cfg into log files: Example from DevStack q-svc.log: [00;32mDEBUG oslo_service.service [^[[00;36m-^[[00;32m] ^[[01;35m^[[00;32mservice_auth.admin_password = password Issue is that the cfg.StrOpt for admin_password did not set 'secret=True", which would give: service_auth.admin_password = **** ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1549547 Title: LBaaS leaking password in DEBUG logs Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: Current code leaks the keystone admin_password in the cfg into log files: Example from DevStack q-svc.log: [00;32mDEBUG oslo_service.service [^[[00;36m-^[[00;32m] ^[[01;35m^[[00;32mservice_auth.admin_password = password Issue is that the cfg.StrOpt for admin_password did not set 'secret=True", which would give: service_auth.admin_password = **** To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1549547/+subscriptions From fungi at yuggoth.org Mon Feb 29 16:20:24 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 29 Feb 2016 16:20:24 -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: <20160229162024.2009.24773.malone@gac.canonical.com> The way I would usually expect distributions to try and solve situations like this is to define a common openstack-images system group, add the nova and qemu users to it, make the containing directory setgid owned by nova with group openstack-images, and set an appropriately strict umask when calling nova so that it creates group-readable but non-world- readable files. As long as there are ways to convince nova to obey setgid and umask (assuming it doesn't already), this should be doable, right? -- You received this bug notification because you are a member of OpenStack Security, 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): Opinion Status in OpenStack Security Advisory: Incomplete 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 grant.murphy at hp.com Mon Feb 29 16:40:45 2016 From: grant.murphy at hp.com (Grant Murphy) Date: Mon, 29 Feb 2016 16:40:45 -0000 Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for OSSA-2015-005 References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com> Message-ID: <20160229164045.1658.91382.malone@wampee.canonical.com> Given this analysis I propose we close this as notabug and remove the OSSA task. Any objections? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1511541 Title: Possible incomplete fix for OSSA-2015-005 Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Incomplete Bug description: Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete. https://bugs.launchpad.net/nova/+bug/1409142/comments/146 https://bugs.launchpad.net/nova/+bug/1409142/comments/149 Further investigation is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1511541/+subscriptions From 1516031 at bugs.launchpad.net Mon Feb 29 18:20:46 2016 From: 1516031 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 29 Feb 2016 18:20:46 -0000 Subject: [Openstack-security] [Bug 1516031] Fix merged to glance (master) References: <20151113142716.4469.80964.malonedeb@gac.canonical.com> Message-ID: <20160229182046.1925.59851.malone@gac.canonical.com> Reviewed: https://review.openstack.org/255584 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=95ca43f30f5bcc8107e0615b3861daa2c77a2aec Submitter: Jenkins Branch: master commit 95ca43f30f5bcc8107e0615b3861daa2c77a2aec Author: Brianna Poulos Date: Tue Dec 8 17:24:11 2015 -0500 Add sign-the-data signature verification Per discussion on the mailing list [1] and the related nova specification [2] it has been decided that the signature should be of the image data directly, rather than of the glance MD5 "checksum" hash of the image data. This patch adds the ability to verify a signature of the image data directly, using a verifier that is passed to the glance_store backend. It is dependent on a glance_store patch which updates this verifier object with the image data as it is creating the checksum (see Depends-On below). [1] http://bit.ly/1Q0M0C7 [2] https://review.openstack.org/#/c/188874/19 Depends-On: I43799e6a4a6643a23769af8d839a2beb4e0ff9bf Partial-Bug: #1516031 Change-Id: If0c06b3094cecef6c8ca8a65753038b6b5a9d8fe -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1516031 Title: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234) Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: This have been reported by Daniel P. Berrange: " In the OpenStack Liberty release, the Glance project added support for image signature verification. http://specs.openstack.org/openstack/glance-specs/specs/liberty/image- signing-and-verification-support.html The verification code was added in the following git commit https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e Unfortunately the design of this signature verification method is flawed by design. The generalized approach to creating signatures of content is to apply a hash to the content and then encrypt it in some manner. Consider that the signature is defined to use hash=sha256 and cipher=rsa we can describe the signature computation as signature = rsa(sha256(content)) In the case of verifying a disk image, the content we care about verifying is the complete disk image file. Unfortunately, the glance specification chose *not* to compute the signature against the disk image file. Glance already had an MD5 checksum calculated for the disk image file, so they instead chose to compute the signature against the MD5 checksum instead. ie glance is running signature = rsa(sha256(md5(disk-image-content))) This degrades the security of the system to that of the weakest hash, which is obviously MD5 here. The code where glance verifies the signature is in the glance/locations.py, the 'set_data' method where is does result = signature_utils.verify_signature( self.context, checksum, self.image.extra_properties) if result: LOG.info(_LI("Successfully verified signature for image %s"), self.image.image_id) The 'checksum' variable is populate by the glance_store driver, but it is hardcoded to always be md5 in all current glance storage backends: $ git grep hashlib glance_store/_drivers/ | grep checksum glance_store/_drivers/filesystem.py: checksum = hashlib.md5() glance_store/_drivers/rbd.py: checksum = hashlib.md5() glance_store/_drivers/s3.py: checksum = hashlib.md5() glance_store/_drivers/s3.py: checksum = hashlib.md5() glance_store/_drivers/sheepdog.py: checksum = hashlib.md5() glance_store/_drivers/swift/store.py: checksum = hashlib.md5() glance_store/_drivers/vmware_datastore.py: self.checksum = hashlib.md5() Since we will soon be shipping OpenStack Liberty release, we need to at least give a security notice to alert our customers to the fact that the signature verification is cryptographically weak/broken. IMHO, it quite likely deserves a CVE though NB, this is public knowledge as I first became aware of this flawed design in comments / discussion on a public specification proposed to implement the same approach in the Nova project. My suggested way to fix this is to simply abandon the current impl and re-do it such that it directly computes the signature against the disk image, and does not use the existing md5 checksum in any way. Regards, Daniel " Mailing list thread for Nova impl: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html Nova Spec: https://review.openstack.org/#/c/188874/ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1516031/+subscriptions From gerrit2 at review.openstack.org Mon Feb 29 18:57:30 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 29 Feb 2016 18:57:30 +0000 Subject: [Openstack-security] [openstack/oslo.middleware] SecurityImpact review request change I50a70d477613025d3e54e4ee773bbb1d6fcf2e68 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/283052 Log: commit a0d3007144c3a3422a169a7a5c1d5c47c557701a Author: Juan Antonio Osorio Robles Date: Mon Feb 22 14:07:50 2016 +0200 Disable http_proxy_to_wsgi middleware by default Having this middleware as default is very convenient for deployments, since this enables the application to handle the appropriate headers correctly in order to deal with SSL, which is nice to have out of the box. Heat, for instance, has already taken this middleware as default. However, having this act on the headers by default may not be so desirable, as the application may not be in front of a proxy, and thus will have nothing that parses or strips the X-Forwarded-* headers. Which can lead to security problems. Thus, this patch proposes the enabling of this functionality through a configuration option. This will enable more projects to take this middleware into use by default, and the deployer would only need to change one configuration file; while leaving the paste configuration intact. Change-Id: I50a70d477613025d3e54e4ee773bbb1d6fcf2e68 SecurityImpact From tdecacqu at redhat.com Mon Feb 29 21:09:54 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 29 Feb 2016 21:09:54 -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: <20160229210954.2054.12022.malone@wampee.canonical.com> The /var/lib/nova/instances directory is likely to be a packaging issue, I don't know how disk image mode bits are set, but at least the disk info is explicitly written as 644 by nova/virt/libvirt/imagebackend.py. Anyway I closed the OSSA task since multi-user system is not a realistic threat for openstack system. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix 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 1499555 at bugs.launchpad.net Mon Feb 29 22:23:46 2016 From: 1499555 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 29 Feb 2016 22:23:46 -0000 Subject: [Openstack-security] [Bug 1499555] Change abandoned on keystone (master) References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20160229222346.2093.3102.malone@gac.canonical.com> Change abandoned by Ron De Rose (ronald.de.rose at intel.com) on branch: master Review: https://review.openstack.org/239948 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From sean at dague.net Tue Feb 9 14:20:58 2016 From: sean at dague.net (Sean Dague) Date: Tue, 09 Feb 2016 14:20:58 -0000 Subject: [Openstack-security] [Bug 1450798] Re: Multiple command injection vulns in schema_diff tool References: <20150501135051.16168.63595.malonedeb@gac.canonical.com> Message-ID: <20160209141515.31939.67109.malone@wampee.canonical.com> really? Please actually look at the code a little bit before filing security bugs. This is a very specific tool used to compare the state of migrations. It's not installed as part of normal nova process. ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1450798 Title: Multiple command injection vulns in schema_diff tool Status in OpenStack Compute (nova): Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: These lines in the latest Nova (as of May 1, 2015) are vulnerable to command injection https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117 In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 ), if a malicious filename such as "; rm -rf /etc" is provided, the /etc directory will be removed with the privileges of the user running this script. In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. In this case(https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. I'm not familiar enough with the usage of this module to know all of the places these inputs can come from, but presumably it can be used in automation, potentially with elevated privileges. I'm sure the idea of this script is to allow certain functionality, not unrestricted commands. The way this has been developed allows unrestricted command execution by tampering with any of the above mentioned inputs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1450798/+subscriptions From sean at dague.net Fri Feb 19 20:50:33 2016 From: sean at dague.net (Sean Dague) Date: Fri, 19 Feb 2016 20:50:33 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160219205033.2409.3346.malone@gac.canonical.com> I do feel like private key format is not part of the nova contract. I'm sorry Go tools are so limitted with what they support. The right path is working with upstream paramiko on this. ** Changed in: nova Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Won't Fix Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From sean at dague.net Sat Feb 20 01:46:18 2016 From: sean at dague.net (Sean Dague) Date: Sat, 20 Feb 2016 01:46:18 -0000 Subject: [Openstack-security] [Bug 1391504] Re: Sample policies for Openstack References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20160220014624.2415.25090.launchpad@soybean.canonical.com> ** Changed in: nova Status: Confirmed => Opinion ** Changed in: nova Importance: Low => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1391504 Title: Sample policies for Openstack Status in Cinder: Triaged Status in Glance: In Progress Status in OpenStack Identity (keystone): Confirmed Status in neutron: In Progress Status in OpenStack Compute (nova): Opinion Bug description: Regarding OpenStack policies, in general, the described roles seem quite complicated, it is not clear which roles are appropriated for each user. For example, in many policies it is defined just a global admin role. We would like to clarify what are the role organizations, for example, cloud_admin is the role for the cloud managers, domain_admin is the role for the domain managers, project_admin for the project admin and project_member a member with a role in a project but with no admin permissions. In this way, it is clear for the cloud manager which capability is being given to a user. The idea is create a policy.cloudsample.json, where roles as cloud_admin project_admin, and project_member will be defined and some default permissions, making policies closer to the business reality. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1391504/+subscriptions From sean at dague.net Sat Feb 20 10:16:23 2016 From: sean at dague.net (Sean Dague) Date: Sat, 20 Feb 2016 10:16:23 -0000 Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict should have a password key rather than clear password References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20160220101623.1497.11428.malone@chaenomeles.canonical.com> I'm assuming we just pick this up from oslo.vo and there isn't a nova change? ** Changed in: nova Status: Confirmed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): Fix Released Status in oslo.versionedobjects: Fix Released Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From sean at dague.net Sat Feb 20 15:36:38 2016 From: sean at dague.net (Sean Dague) Date: Sat, 20 Feb 2016 15:36:38 -0000 Subject: [Openstack-security] [Bug 1516703] Re: crypto.py generates certs with SHA-1 digest References: <20151116164718.17403.87965.malonedeb@gac.canonical.com> Message-ID: <20160220153639.1547.35262.launchpad@gac.canonical.com> ** Changed in: nova Importance: Undecided => Medium ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1516703 Title: crypto.py generates certs with SHA-1 digest Status in OpenStack Compute (nova): In Progress Bug description: nova/crypto.py:generate_winrm_x509_cert() generates certs with default SHA-1 digest. The call to 'openssl req' does not specify -digest option nor certificate config file sets digest, so certificates are generated with SHA-1 digest. SHA-1 is not considered to be a secure algorithm for certificates' digest. It would be preferable to: 1) let user specify digest algorithm via a config option 2) default to SHA-256 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1516703/+subscriptions From swann at oopss.org Fri Feb 26 12:52:20 2016 From: swann at oopss.org (Swann Croiset) Date: Fri, 26 Feb 2016 12:52:20 -0000 Subject: [Openstack-security] [Bug 1550330] [NEW] Elasticsearch plugin fails to build - ca-certificates package update Message-ID: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Public bug reported: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb ** Affects: lma-toolchain Importance: High Assignee: Swann Croiset (swann-w) Status: In Progress ** Affects: lma-toolchain/0.8 Importance: Undecided Status: New ** Affects: lma-toolchain/0.9 Importance: Undecided Status: New ** Tags: package security ** Summary changed: - Elasticsearch plugin fails to build ca-certificats changes + Elasticsearch plugin fails to build - ca-certificates package update -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: In Progress Status in LMA Toolchain 0.8 series: New Status in LMA Toolchain 0.9 series: New Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From swann at oopss.org Fri Feb 26 12:55:08 2016 From: swann at oopss.org (Swann Croiset) Date: Fri, 26 Feb 2016 12:55:08 -0000 Subject: [Openstack-security] [Bug 1550330] Re: Elasticsearch plugin fails to build - ca-certificates package update References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160226125509.2093.59219.launchpad@wampee.canonical.com> ** Also affects: lma-toolchain/0.9 Importance: Undecided Status: New ** Also affects: lma-toolchain/0.8 Importance: Undecided Status: New ** Changed in: lma-toolchain/0.8 Milestone: None => 0.8.1 ** Changed in: lma-toolchain/0.9 Milestone: None => 0.9.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: In Progress Status in LMA Toolchain 0.8 series: New Status in LMA Toolchain 0.9 series: New Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions