From 1305566 at bugs.launchpad.net Mon Aug 1 02:39:42 2016 From: 1305566 at bugs.launchpad.net (Steve Martinelli) Date: Mon, 01 Aug 2016 02:39:42 -0000 Subject: [Openstack-security] [Bug 1305566] Re: the token still can be used if the EC2 credential has been deleted References: <20140410083249.25765.8738.malonedeb@soybean.canonical.com> Message-ID: <20160801023942.20403.30655.malone@wampee.canonical.com> unassigning due to inactivity ** Changed in: keystone Assignee: Ron De Rose (ronald-de-rose) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1305566 Title: the token still can be used if the EC2 credential has been deleted Status in OpenStack Identity (keystone): Confirmed Bug description: Currently, the associated tokens are not deleted when deleting ec2 credential. So, the token got before can still be used. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1305566/+subscriptions From 1268751 at bugs.launchpad.net Mon Aug 1 20:02:37 2016 From: 1268751 at bugs.launchpad.net (Steve Martinelli) Date: Mon, 01 Aug 2016 20:02:37 -0000 Subject: [Openstack-security] [Bug 1268751] Re: Potential token revocation abuse via group membership References: <20140113215431.25014.35474.malonedeb@chaenomeles.canonical.com> Message-ID: <20160801200238.21093.31166.malone@wampee.canonical.com> Automatically unassigning due to inactivity. ** Changed in: keystone Assignee: Lance Bragstad (lbragstad) => (unassigned) -- 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 1534288 at bugs.launchpad.net Mon Aug 1 20:06:41 2016 From: 1534288 at bugs.launchpad.net (Steve Martinelli) Date: Mon, 01 Aug 2016 20:06:41 -0000 Subject: [Openstack-security] [Bug 1534288] Re: keystoneclient should not be using pickle References: <20160114195928.28540.47395.malonedeb@gac.canonical.com> Message-ID: <20160801200641.29518.27332.malone@gac.canonical.com> Automatically unassigning due to inactivity. ** Changed in: python-keystoneclient Assignee: Brant Knudson (blk-u) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534288 Title: keystoneclient should not be using pickle Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: New Bug description: keystoneclient uses pickle to pull the keystoneclient_auth value out of the keyring. pickle is not safe to use since it can run commands as the user. I guess someone could use this to run some code as the nova user by putting something into the keystoneclient_auth value in the nova user's keyring and then getting nova to use keystoneclient.httpclient. There's probably a safer way to do serialize the auth info using JSON or some other format. Opening this as private security since there's a potential attack here although I don't have any proof. This was found using bandit 0.17.0. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1534288/+subscriptions From 1534288 at bugs.launchpad.net Mon Aug 1 23:26:31 2016 From: 1534288 at bugs.launchpad.net (Steve Martinelli) Date: Mon, 01 Aug 2016 23:26:31 -0000 Subject: [Openstack-security] [Bug 1534288] Re: keystoneclient should not be using pickle References: <20160114195928.28540.47395.malonedeb@gac.canonical.com> Message-ID: <20160801232631.20651.92334.malone@wampee.canonical.com> As Brant mentioned in #1, the content using pickle is deprecated [1]. Since we haven't had any issues with this in many years I'd prefer to mark this as Won't Fix and resolve this issue when we eventually remove the httpclient code. Thoughts? [1] https://github.com/openstack/python- keystoneclient/blob/fb2fef9100beeaaa281e1e7ddef48e9eea327c70/keystoneclient/httpclient.py#L32 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534288 Title: keystoneclient should not be using pickle Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: New Bug description: keystoneclient uses pickle to pull the keystoneclient_auth value out of the keyring. pickle is not safe to use since it can run commands as the user. I guess someone could use this to run some code as the nova user by putting something into the keystoneclient_auth value in the nova user's keyring and then getting nova to use keystoneclient.httpclient. There's probably a safer way to do serialize the auth info using JSON or some other format. Opening this as private security since there's a potential attack here although I don't have any proof. This was found using bandit 0.17.0. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1534288/+subscriptions From 1541122 at bugs.launchpad.net Tue Aug 2 13:01:49 2016 From: 1541122 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 02 Aug 2016 13:01:49 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160802130149.16543.42083.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/325897 Committed: https://git.openstack.org/cgit/openstack/sahara/commit/?id=d29b4cfd04e201500e861086e86274a443243eba Submitter: Jenkins Branch: master commit d29b4cfd04e201500e861086e86274a443243eba Author: Mikhail Lelyakin Date: Mon Jun 6 15:49:40 2016 +0300 Remove hardcoded password for Oozie service Change will correct the oozie configuration to use a random password instead of the hardcoded one currently in use. Closes-bug: 1541122 Change-Id: I31c54aefc3c3ac65d928d9892be485ac754b6b10 ** Changed in: sahara Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Won't Fix Status in Sahara: Fix Released Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From 1246160 at bugs.launchpad.net Thu Aug 4 17:39:57 2016 From: 1246160 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 04 Aug 2016 17:39:57 -0000 Subject: [Openstack-security] [Bug 1246160] Change abandoned on nova (master) References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com> Message-ID: <20160804173957.16512.68530.malone@chaenomeles.canonical.com> Change abandoned by Matt Riedemann (mriedem at us.ibm.com) on branch: master Review: https://review.openstack.org/210092 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246160 Title: shuffle method bring potential security issue Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Invalid Bug description: In the /nova/utils.py, line 328, the source code is below r.shuffle(password) This code is using shuffle method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246160/+subscriptions From 1605914 at bugs.launchpad.net Fri Aug 5 12:41:27 2016 From: 1605914 at bugs.launchpad.net (Amrith) Date: Fri, 05 Aug 2016 12:41:27 -0000 Subject: [Openstack-security] [Bug 1605914] Re: Hard coded security group References: <20160723182211.8674.89923.malonedeb@soybean.canonical.com> Message-ID: <20160805124128.17381.65380.launchpad@chaenomeles.canonical.com> ** Changed in: trove Milestone: None => ocata-1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1605914 Title: Hard coded security group Status in OpenStack DBaaS (Trove): Confirmed Bug description: "trove create" also creates a security group, with hard coded values. Some of which is not what I want/need - especially the 'allow everything' rule! Please allow to specify existing SG(s) (preferably plural) on either the command line (preferably), or in the datastore/datastore_version configuration. Or possibly in the datastore section in trove*.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/trove/+bug/1605914/+subscriptions From 1568070 at bugs.launchpad.net Mon Aug 8 23:43:32 2016 From: 1568070 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 08 Aug 2016 23:43:32 -0000 Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which changes require a reboot References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com> Message-ID: <20160808234333.29836.94874.launchpad@gac.canonical.com> ** Changed in: openstack-ansible Assignee: Ian Cordasco (icordasc) => Christian Berendt (berendt-betacloud) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568070 Title: Security: Identify which changes require a reboot Status in openstack-ansible: In Progress Bug description: Some changes made by openstack-ansible-security require a reboot. It would be nice to alert the deployer to those changes at the end of the playbook run so they know if they had a change made that requires a reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568070/+subscriptions From gerrit2 at review.openstack.org Thu Aug 11 17:44:29 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 11 Aug 2016 17:44:29 +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 10f5a920ea434acb2fda06ba3e087968cddb719f 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. Moving spec from mitaka to newton directory. Added field to capture crypto_plugin name in addition to secret store plugin name. This is done as both software only and pkcs11 plugin uses database (store_crypto) as storage backend. Difference is in crypto plugin used (simple crypto vs p11_crypto). APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From gerrit2 at review.openstack.org Thu Aug 11 17:49:12 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 11 Aug 2016 17:49:12 +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 b31d5013cac07abd74aa3c5b1ff29780f8a76aa8 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. Moving spec from mitaka to newton directory. Added field to capture crypto_plugin name in addition to secret store plugin name. This is done as both software only and pkcs11 plugin uses database (store_crypto) as storage backend. Difference is in crypto plugin used (simple crypto vs p11_crypto). APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From major at mhtx.net Fri Aug 12 14:57:02 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 12 Aug 2016 14:57:02 -0000 Subject: [Openstack-security] [Bug 1612688] [NEW] rpmverify check on auditd fails Message-ID: <20160812145702.22947.19301.malonedeb@soybean.canonical.com> Public bug reported: The Ansible task for V-38637 fails because some additional configuration files have changed from the auditd package defaults. TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : V-38637 - Contents of auditd package must be verified] *** fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Could not verify that files from auditd package are unaltered"} ** Affects: openstack-ansible Importance: High Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1612688 Title: rpmverify check on auditd fails Status in openstack-ansible: New Bug description: The Ansible task for V-38637 fails because some additional configuration files have changed from the auditd package defaults. TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : V-38637 - Contents of auditd package must be verified] *** fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Could not verify that files from auditd package are unaltered"} To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1612688/+subscriptions From gerrit2 at review.openstack.org Tue Aug 16 20:52:42 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 16 Aug 2016 20:52: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 87d7ca3003b29f5c5ecdb9edf74d03d859ed3911 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. Added details around plugin name and how its used in secret_stores 'name' field. Moving spec from mitaka to newton directory. Added field to capture crypto_plugin name in addition to secret store plugin name. This is done as both software only and pkcs11 plugin uses database (store_crypto) as storage backend. Difference is in crypto plugin used (simple crypto vs p11_crypto). APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From gerrit2 at review.openstack.org Tue Aug 16 20:56:07 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 16 Aug 2016 20:56:07 +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 359a5011e2aaf83ffb809c5c69f362083ade7895 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. Added details around plugin name and how its used in secret_stores 'name' field. Moving spec from mitaka to newton directory. Added field to capture crypto_plugin name in addition to secret store plugin name. This is done as both software only and pkcs11 plugin uses database (store_crypto) as storage backend. Difference is in crypto plugin used (simple crypto vs p11_crypto). APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From morgan.fainberg at gmail.com Wed Aug 17 01:26:11 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 17 Aug 2016 01:26:11 -0000 Subject: [Openstack-security] [Bug 1613901] Re: String "..%c0%af" causes 500 errors in multiple locations in Keystone v3 References: <20160816233137.14656.30722.malonedeb@soybean.canonical.com> Message-ID: <20160817012611.17239.52050.malone@chaenomeles.canonical.com> I have marked this bug as public and since this is not a security related bug, the OSSA task has been marked as "Wont Fix". Thanks Steve and Dolph for the quick response. ** 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. - - While doing some testing on Keystone using Syntribos (https://github.com/openstack/syntribos), our team (myself, Michael Dong, Rahul U Nair, Vinay Potluri, Aastha Dixit, and Khanak Nangia) noticed that we got 500 status codes when the string "..%c0%af" was inserted in various places in the URL for different types of requests. + While doing some testing on Keystone using Syntribos + (https://github.com/openstack/syntribos), our team (myself, Michael + Dong, Rahul U Nair, Vinay Potluri, Aastha Dixit, and Khanak Nangia) + noticed that we got 500 status codes when the string "..%c0%af" was + inserted in various places in the URL for different types of requests. Here are some examples: ========= DELETE /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] Content-Length: 0 HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:04:27 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-238fd5a9-be45-41f2-893a-97b513b27af3 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= PATCH /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 Content-type: application/json X-Auth-Token: [REDACTED] Content-Length: 70 {"type": "--serialization-mime-type--", "blob": "--serialized-blob--"} HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:05:36 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-57a41600-02b4-4d2a-b3e9-40f7724d65f2 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= GET /v3/domains/0426ac1e48f642ef9544c2251e07e261/groups/..%c0%af/roles HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:07:09 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-02313f77-63c6-4aa8-a87e-e3d2a13ad6b7 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= I've marked this as a security issue as a precaution in case it turns out that there is a more serious vulnerability underlying these errors. We have no reason to suspect that there is a greater vulnerability at this time, but given the many endpoints this seems to affect, I figured caution was worthwhile since this may be a framework-wide issue. Feel free to make this public if it is determined not to be security- impacting. Here is a (possibly incomplete) list of affected endpoints. Inserting the string "..%c0%af" in any or all of the spots labeled "HERE" should yield a 500 error. As you can see, virtually all v3 endpoints exhibit this behavior. ========= [GET|PATCH|DELETE] /v3/endpoints/[HERE] [GET|PATCH] /v3/domains/[HERE] GET /v3/domains/[HERE]/groups/[HERE]/roles [HEAD|PUT|DELETE] /v3/domains/[HERE]/groups/[HERE]/roles/[HERE] GET /v3/domains/[HERE]/users/[HERE]/roles [HEAD|DELETE] /v3/domains/[HERE]/users/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/groups/[HERE] [HEAD|PUT|DELETE] /v3/groups[HERE]/users/[HERE] [POST|DELETE] /v3/keys/[HERE] [GET|PATCH|DELETE] /v3/policies/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/endpoints/[HERE] [GET|HEAD] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/policy [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/regions/[HERE] [GET|PATCH|DELETE] /v3/projects/[HERE] [DELETE|PATCH] /v3/projects/[HERE]/cascade GET /v3/projects/[HERE]/groups/[HERE]/roles GET /v3/projects/[HERE]/users/[HERE]/roles [HEAD|PUT|DELETE] /v3/projects/[HERE]/groups/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/regions/[HERE] [PATCH|DELETE] /v3/roles/[HERE] [GET|PATCH|DELETE] /v3/services/[HERE] [GET|PATCH|DELETE] /v3/users/[HERE] GET /v3/users/[HERE]/groups POST /v3/users/[HERE]/password GET /v3/users/[HERE]/projects GET /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/OS-OAUTH1/consumers/[HERE] [GET|DELETE] /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE] ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1613901 Title: String "..%c0%af" causes 500 errors in multiple locations in Keystone v3 Status in OpenStack Identity (keystone): Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: While doing some testing on Keystone using Syntribos (https://github.com/openstack/syntribos), our team (myself, Michael Dong, Rahul U Nair, Vinay Potluri, Aastha Dixit, and Khanak Nangia) noticed that we got 500 status codes when the string "..%c0%af" was inserted in various places in the URL for different types of requests. Here are some examples: ========= DELETE /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] Content-Length: 0 HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:04:27 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-238fd5a9-be45-41f2-893a-97b513b27af3 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= PATCH /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 Content-type: application/json X-Auth-Token: [REDACTED] Content-Length: 70 {"type": "--serialization-mime-type--", "blob": "--serialized-blob--"} HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:05:36 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-57a41600-02b4-4d2a-b3e9-40f7724d65f2 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= GET /v3/domains/0426ac1e48f642ef9544c2251e07e261/groups/..%c0%af/roles HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:07:09 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-02313f77-63c6-4aa8-a87e-e3d2a13ad6b7 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= I've marked this as a security issue as a precaution in case it turns out that there is a more serious vulnerability underlying these errors. We have no reason to suspect that there is a greater vulnerability at this time, but given the many endpoints this seems to affect, I figured caution was worthwhile since this may be a framework-wide issue. Feel free to make this public if it is determined not to be security-impacting. Here is a (possibly incomplete) list of affected endpoints. Inserting the string "..%c0%af" in any or all of the spots labeled "HERE" should yield a 500 error. As you can see, virtually all v3 endpoints exhibit this behavior. ========= [GET|PATCH|DELETE] /v3/endpoints/[HERE] [GET|PATCH] /v3/domains/[HERE] GET /v3/domains/[HERE]/groups/[HERE]/roles [HEAD|PUT|DELETE] /v3/domains/[HERE]/groups/[HERE]/roles/[HERE] GET /v3/domains/[HERE]/users/[HERE]/roles [HEAD|DELETE] /v3/domains/[HERE]/users/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/groups/[HERE] [HEAD|PUT|DELETE] /v3/groups[HERE]/users/[HERE] [POST|DELETE] /v3/keys/[HERE] [GET|PATCH|DELETE] /v3/policies/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/endpoints/[HERE] [GET|HEAD] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/policy [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/regions/[HERE] [GET|PATCH|DELETE] /v3/projects/[HERE] [DELETE|PATCH] /v3/projects/[HERE]/cascade GET /v3/projects/[HERE]/groups/[HERE]/roles GET /v3/projects/[HERE]/users/[HERE]/roles [HEAD|PUT|DELETE] /v3/projects/[HERE]/groups/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/regions/[HERE] [PATCH|DELETE] /v3/roles/[HERE] [GET|PATCH|DELETE] /v3/services/[HERE] [GET|PATCH|DELETE] /v3/users/[HERE] GET /v3/users/[HERE]/groups POST /v3/users/[HERE]/password GET /v3/users/[HERE]/projects GET /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/OS-OAUTH1/consumers/[HERE] [GET|DELETE] /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE] To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1613901/+subscriptions From 1613901 at bugs.launchpad.net Wed Aug 17 02:39:58 2016 From: 1613901 at bugs.launchpad.net (Steve Martinelli) Date: Wed, 17 Aug 2016 02:39:58 -0000 Subject: [Openstack-security] [Bug 1613901] Re: String "..%c0%af" causes 500 errors in multiple locations in Keystone v3 References: <20160816233137.14656.30722.malonedeb@soybean.canonical.com> Message-ID: <20160817023959.16941.76422.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Importance: Undecided => Low -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1613901 Title: String "..%c0%af" causes 500 errors in multiple locations in Keystone v3 Status in OpenStack Identity (keystone): Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: While doing some testing on Keystone using Syntribos (https://github.com/openstack/syntribos), our team (myself, Michael Dong, Rahul U Nair, Vinay Potluri, Aastha Dixit, and Khanak Nangia) noticed that we got 500 status codes when the string "..%c0%af" was inserted in various places in the URL for different types of requests. Here are some examples: ========= DELETE /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] Content-Length: 0 HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:04:27 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-238fd5a9-be45-41f2-893a-97b513b27af3 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= PATCH /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 Content-type: application/json X-Auth-Token: [REDACTED] Content-Length: 70 {"type": "--serialization-mime-type--", "blob": "--serialized-blob--"} HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:05:36 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-57a41600-02b4-4d2a-b3e9-40f7724d65f2 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= GET /v3/domains/0426ac1e48f642ef9544c2251e07e261/groups/..%c0%af/roles HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:07:09 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-02313f77-63c6-4aa8-a87e-e3d2a13ad6b7 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= I've marked this as a security issue as a precaution in case it turns out that there is a more serious vulnerability underlying these errors. We have no reason to suspect that there is a greater vulnerability at this time, but given the many endpoints this seems to affect, I figured caution was worthwhile since this may be a framework-wide issue. Feel free to make this public if it is determined not to be security-impacting. Here is a (possibly incomplete) list of affected endpoints. Inserting the string "..%c0%af" in any or all of the spots labeled "HERE" should yield a 500 error. As you can see, virtually all v3 endpoints exhibit this behavior. ========= [GET|PATCH|DELETE] /v3/endpoints/[HERE] [GET|PATCH] /v3/domains/[HERE] GET /v3/domains/[HERE]/groups/[HERE]/roles [HEAD|PUT|DELETE] /v3/domains/[HERE]/groups/[HERE]/roles/[HERE] GET /v3/domains/[HERE]/users/[HERE]/roles [HEAD|DELETE] /v3/domains/[HERE]/users/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/groups/[HERE] [HEAD|PUT|DELETE] /v3/groups[HERE]/users/[HERE] [POST|DELETE] /v3/keys/[HERE] [GET|PATCH|DELETE] /v3/policies/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/endpoints/[HERE] [GET|HEAD] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/policy [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/regions/[HERE] [GET|PATCH|DELETE] /v3/projects/[HERE] [DELETE|PATCH] /v3/projects/[HERE]/cascade GET /v3/projects/[HERE]/groups/[HERE]/roles GET /v3/projects/[HERE]/users/[HERE]/roles [HEAD|PUT|DELETE] /v3/projects/[HERE]/groups/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/regions/[HERE] [PATCH|DELETE] /v3/roles/[HERE] [GET|PATCH|DELETE] /v3/services/[HERE] [GET|PATCH|DELETE] /v3/users/[HERE] GET /v3/users/[HERE]/groups POST /v3/users/[HERE]/password GET /v3/users/[HERE]/projects GET /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/OS-OAUTH1/consumers/[HERE] [GET|DELETE] /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE] To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1613901/+subscriptions From 1613901 at bugs.launchpad.net Wed Aug 17 04:23:11 2016 From: 1613901 at bugs.launchpad.net (Robert Clark) Date: Wed, 17 Aug 2016 04:23:11 -0000 Subject: [Openstack-security] [Bug 1613901] Re: String "..%c0%af" causes 500 errors in multiple locations in Keystone v3 References: <20160816233137.14656.30722.malonedeb@soybean.canonical.com> Message-ID: <20160817042311.17416.16176.malone@chaenomeles.canonical.com> Seems reasonable to me. Well done on finding this Syntribos team - this tool is showing real promise. I'm expecting you to find some interesting higher-severity issues 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/1613901 Title: String "..%c0%af" causes 500 errors in multiple locations in Keystone v3 Status in OpenStack Identity (keystone): Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: While doing some testing on Keystone using Syntribos (https://github.com/openstack/syntribos), our team (myself, Michael Dong, Rahul U Nair, Vinay Potluri, Aastha Dixit, and Khanak Nangia) noticed that we got 500 status codes when the string "..%c0%af" was inserted in various places in the URL for different types of requests. Here are some examples: ========= DELETE /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] Content-Length: 0 HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:04:27 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-238fd5a9-be45-41f2-893a-97b513b27af3 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= PATCH /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 Content-type: application/json X-Auth-Token: [REDACTED] Content-Length: 70 {"type": "--serialization-mime-type--", "blob": "--serialized-blob--"} HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:05:36 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-57a41600-02b4-4d2a-b3e9-40f7724d65f2 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= GET /v3/domains/0426ac1e48f642ef9544c2251e07e261/groups/..%c0%af/roles HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:07:09 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-02313f77-63c6-4aa8-a87e-e3d2a13ad6b7 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= I've marked this as a security issue as a precaution in case it turns out that there is a more serious vulnerability underlying these errors. We have no reason to suspect that there is a greater vulnerability at this time, but given the many endpoints this seems to affect, I figured caution was worthwhile since this may be a framework-wide issue. Feel free to make this public if it is determined not to be security-impacting. Here is a (possibly incomplete) list of affected endpoints. Inserting the string "..%c0%af" in any or all of the spots labeled "HERE" should yield a 500 error. As you can see, virtually all v3 endpoints exhibit this behavior. ========= [GET|PATCH|DELETE] /v3/endpoints/[HERE] [GET|PATCH] /v3/domains/[HERE] GET /v3/domains/[HERE]/groups/[HERE]/roles [HEAD|PUT|DELETE] /v3/domains/[HERE]/groups/[HERE]/roles/[HERE] GET /v3/domains/[HERE]/users/[HERE]/roles [HEAD|DELETE] /v3/domains/[HERE]/users/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/groups/[HERE] [HEAD|PUT|DELETE] /v3/groups[HERE]/users/[HERE] [POST|DELETE] /v3/keys/[HERE] [GET|PATCH|DELETE] /v3/policies/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/endpoints/[HERE] [GET|HEAD] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/policy [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/regions/[HERE] [GET|PATCH|DELETE] /v3/projects/[HERE] [DELETE|PATCH] /v3/projects/[HERE]/cascade GET /v3/projects/[HERE]/groups/[HERE]/roles GET /v3/projects/[HERE]/users/[HERE]/roles [HEAD|PUT|DELETE] /v3/projects/[HERE]/groups/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/regions/[HERE] [PATCH|DELETE] /v3/roles/[HERE] [GET|PATCH|DELETE] /v3/services/[HERE] [GET|PATCH|DELETE] /v3/users/[HERE] GET /v3/users/[HERE]/groups POST /v3/users/[HERE]/password GET /v3/users/[HERE]/projects GET /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/OS-OAUTH1/consumers/[HERE] [GET|DELETE] /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE] To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1613901/+subscriptions From 1568070 at bugs.launchpad.net Wed Aug 17 13:10:21 2016 From: 1568070 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 17 Aug 2016 13:10:21 -0000 Subject: [Openstack-security] [Bug 1568070] Change abandoned on openstack-ansible-security (master) References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com> Message-ID: <20160817131021.29660.92354.malone@gac.canonical.com> Change abandoned by Ian Cordasco (ian.cordasco at rackspace.com) on branch: master Review: https://review.openstack.org/310067 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568070 Title: Security: Identify which changes require a reboot Status in openstack-ansible: In Progress Bug description: Some changes made by openstack-ansible-security require a reboot. It would be nice to alert the deployer to those changes at the end of the playbook run so they know if they had a change made that requires a reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568070/+subscriptions From 1613199 at bugs.launchpad.net Wed Aug 17 18:07:07 2016 From: 1613199 at bugs.launchpad.net (Augustina Ragwitz) Date: Wed, 17 Aug 2016 18:07:07 -0000 Subject: [Openstack-security] [Bug 1613199] Re: nova does not accept ssh certificate authorities (regression) References: <20160815075845.16694.60193.malonedeb@chaenomeles.canonical.com> Message-ID: <20160817180707.16898.4496.malone@chaenomeles.canonical.com> Here is a link to the change mentioned in the bug report - http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a This change implemented key generation using paramiko. The cert- authority issue has been reported to paramiko - https://github.com/paramiko/paramiko/issues/771 I think this shows a gap in our current test coverage. We should add a test for the "cert-authority" case as described above. I am confirming this bug to add this test coverage. ** Bug watch added: github.com/paramiko/paramiko/issues #771 https://github.com/paramiko/paramiko/issues/771 ** Changed in: nova Status: New => Confirmed ** Changed in: nova Assignee: (unassigned) => Augustina Ragwitz (auggy) ** 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/1613199 Title: nova does not accept ssh certificate authorities (regression) Status in OpenStack Compute (nova): Confirmed Bug description: Prior to commit 3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a nova/crypto.py generate_fingerprint used ssh-keygen -q -l -f to generate finger prints. ssh-keygen -qlf is quite happy to process public key matter of the form cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun The issue is the string cert-authority at the beginning of the public key matter. This form can appear in authorized_keys to enable multiple users on a project to have individual keys certified by a central certifying authority providing access to a single administrative account. The use of ssh certificates is documented here: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh- ca-to-validate-hosts-and-clients-with-ubuntu Steps to reproduce: 1) Place the string """ cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun """ in a file 2) run nova keypair-add --pub-key Expected result: They nova keypair-list should now list the key Actual result: ERROR (BadRequest): Keypair data is invalid: failed to generate fingerprint (HTTP 400) Environment: Openstack liberty release (bug is not present on kilo) Logs: Sorry, not available (I'm only a user not an admin) Suggest fix: either: 1) revert generate_fingerprint to using exec ssh-keygen 2) generate_fingerprint should strip the string cert-authority from the begining of the public key matter (if present) before attempting to generate the fingerprint. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1613199/+subscriptions From gerrit2 at review.openstack.org Wed Aug 17 19:09:57 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 17 Aug 2016 19:09:57 +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 c8696a64ab5bb7f1e58fb83ccc876db935c24672 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. Added details around plugin name and how its used in secret_stores 'name' field. Moving spec from mitaka to newton directory. Added field to capture crypto_plugin name in addition to secret store plugin name. This is done as both software only and pkcs11 plugin uses database (store_crypto) as storage backend. Difference is in crypto plugin used (simple crypto vs p11_crypto). APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From 1492398 at bugs.launchpad.net Wed Aug 17 23:26:11 2016 From: 1492398 at bugs.launchpad.net (Armando Migliaccio) Date: Wed, 17 Aug 2016 23:26:11 -0000 Subject: [Openstack-security] [Bug 1492398] Re: VXLAN Overlay ping issue when Gateway IP is set to one of local NIC's IP address References: <20150904170107.9123.65334.malonedeb@wampee.canonical.com> Message-ID: <20160817232611.22834.20308.malone@soybean.canonical.com> This bug is > 240 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days. If the bug is still valid, then update the bug status. ** Changed in: neutron 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/1492398 Title: VXLAN Overlay ping issue when Gateway IP is set to one of local NIC's IP address Status in neutron: Incomplete Status in OpenStack Security Advisory: Won't Fix Bug description: 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. There's an issue when a VXLAN overlay VM tries to ping an overlay IP address that is also the same as one of the host machine's local IP addresses. In my setup, I've tried pinging the overlay VM's router's IP address. Here are the details: VXLAN Id is 100 (this number is immaterial, what matters is that we use VXLAN for tenant traffic) Overlay VM: IP: 10.0.1.3/24 GW: 10.0.1.1 Host Info: enp21s0f0: 1.1.1.5/24 (This interface is used to contact the controller as well as for encapsulated datapath traffic. qbr89a962f7-9b: Linux Bridge to which the Overlay VM connects. No IP address on this one. brctl show: qbr89a962f7-9b 8000.56f6fefb9d5c no qvb89a962f7-9b                                                         tap89a962f7-9b ifconfig qbr89a962f7-9b qbr89a962f7-9b: flags=4163 mtu 1500         inet6 fe80::54f6:feff:fefb:9d5c prefixlen 64 scopeid 0x20         ether 56:f6:fe:fb:9d:5c txqueuelen 0 (Ethernet)         RX packets 916 bytes 27072 (26.4 KiB)         RX errors 0 dropped 0 overruns 0 frame 0         TX packets 10 bytes 780 (780.0 B)         TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 I am using a previously unused NIC named eno1 for this example. When eno1 has no IP address, ping from the overlay VM to the router is successful. ARP on the VM shows the correct MAC resolution. When I set eno1 to 10.0.1.1, ARP on the overlay VM show's qbr89a962f7-9b's MAC address and ping never succeeds. When things work OK ARP for 10.0.1.1 is fa:16:3e:0c:52:6d When eno1 is set to 10.0.1.1 ARP resolution is incorrect, 10.0.1.1 resolves to 56:f6:fe:fb:9d:5c and ping never succeeds. I've deleted ARPs to ensure that resolution is triggered. It appears as of the OVS br-int never received the ARP request. Thanks, -Uday To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1492398/+subscriptions From gerrit2 at review.openstack.org Thu Aug 18 04:26:48 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 18 Aug 2016 04:26:48 +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 68df7c0363f60ddb0a787b9d5a5494aa541041a9 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. Added details around plugin name and how its used in secret_stores 'name' field. Added changes related to how multiple plugin configuration is going to be specified and used. Added field to capture crypto_plugin name in addition to secret store plugin name. This is done as both software only and pkcs11 plugin uses database (store_crypto) as storage backend. Difference is in crypto plugin used (simple crypto vs p11_crypto). APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From gerrit2 at review.openstack.org Thu Aug 18 12:05:20 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 18 Aug 2016 12:05:20 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Id2304adeb9490a630e1979bb70037ad8a2656d73 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357151 Log: commit 91dad0689438b1384ae55ed7164555d07793ba81 Author: Peter Hamilton Date: Thu Aug 18 07:45:50 2016 -0400 This spec describes changes to the Cursive library that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of certificate trust store support in Cursive allows Nova admins to control which certificates are allowed to sign images used on their compute nodes. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 SecurityImpact DocImpact Change-Id: Id2304adeb9490a630e1979bb70037ad8a2656d73 From gerrit2 at review.openstack.org Thu Aug 18 12:06:30 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 18 Aug 2016 12:06:30 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Id2304adeb9490a630e1979bb70037ad8a2656d73 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357151 Log: commit 360537ac823002cf832ce20b7412ded8d65773dc Author: Peter Hamilton Date: Thu Aug 18 07:45:50 2016 -0400 Add support for certificate validation This spec describes changes to the Cursive library that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of certificate trust store support in Cursive allows Nova admins to control which certificates are allowed to sign images used on their compute nodes. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 SecurityImpact DocImpact Change-Id: Id2304adeb9490a630e1979bb70037ad8a2656d73 From gerrit2 at review.openstack.org Thu Aug 18 13:13:19 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 18 Aug 2016 13:13:19 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit 97baff182e2d742dff8061aa31489352b410a481 Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 Add certificate validation This change adds support for a certificate trust store. When performing signature verification, all certificates in the trust store are loaded into a certificate verification context. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the trust store. The get_verifier function is updated to accept an additional, optional parameter: trust_store_path. This parameter should contain a valid filesystem path to the directory acting as the certificate trust store. If not provided, it defaults to None and the trust store will be considered empty. SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b From gerrit2 at review.openstack.org Thu Aug 18 13:15:07 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 18 Aug 2016 13:15:07 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit 077ac1896decbd738ac83dff28b5ad882274038c Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 Add certificate validation This change adds support for a certificate trust store. When performing signature verification, all certificates in the trust store are loaded into a certificate verification context. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the trust store. The get_verifier function is updated to accept an additional, optional parameter: trust_store_path. This parameter should contain a valid filesystem path to the directory acting as the certificate trust store. If not provided, it defaults to None and the trust store will be considered empty. For more information on this work, see the spec: https://review.openstack.org/#/c/357151/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b From major at mhtx.net Thu Aug 18 13:30:53 2016 From: major at mhtx.net (Major Hayden) Date: Thu, 18 Aug 2016 13:30:53 -0000 Subject: [Openstack-security] [Bug 1614532] [NEW] V-38670 aide cron job checks fails Message-ID: <20160818133053.29908.84729.malonedeb@gac.canonical.com> Public bug reported: The cron job check for aide's cron job in V-38670 is currently failing and blocking the security gate jobs. 2016-08-17 22:26:51.190872 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : Check for AIDE cron job (for V-38670)] *** 2016-08-17 22:26:51.327211 | ok: [localhost] 2016-08-17 22:26:51.334723 | 2016-08-17 22:26:51.334789 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : V-38670 - System must detect unauthorized changes to software and information] *** 2016-08-17 22:26:51.381252 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "AIDE cron job is missing"} 2016-08-17 22:26:51.387073 | 2016-08-17 22:26:51.387128 | msg: AIDE cron job is missing 2016-08-17 22:26:51.387140 | 2016-08-17 22:26:51.387155 | msg: AIDE cron job is missing The aide package installs properly, but there is no cron job file found within the package. ** Affects: openstack-ansible Importance: High Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1614532 Title: V-38670 aide cron job checks fails Status in openstack-ansible: New Bug description: The cron job check for aide's cron job in V-38670 is currently failing and blocking the security gate jobs. 2016-08-17 22:26:51.190872 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : Check for AIDE cron job (for V-38670)] *** 2016-08-17 22:26:51.327211 | ok: [localhost] 2016-08-17 22:26:51.334723 | 2016-08-17 22:26:51.334789 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : V-38670 - System must detect unauthorized changes to software and information] *** 2016-08-17 22:26:51.381252 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "AIDE cron job is missing"} 2016-08-17 22:26:51.387073 | 2016-08-17 22:26:51.387128 | msg: AIDE cron job is missing 2016-08-17 22:26:51.387140 | 2016-08-17 22:26:51.387155 | msg: AIDE cron job is missing The aide package installs properly, but there is no cron job file found within the package. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1614532/+subscriptions From 1614532 at bugs.launchpad.net Thu Aug 18 15:11:13 2016 From: 1614532 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 18 Aug 2016 15:11:13 -0000 Subject: [Openstack-security] [Bug 1614532] Re: V-38670 aide cron job checks fails References: <20160818133053.29908.84729.malonedeb@gac.canonical.com> Message-ID: <20160818151113.16661.32714.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/357278 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1614532 Title: V-38670 aide cron job checks fails Status in openstack-ansible: In Progress Bug description: The cron job check for aide's cron job in V-38670 is currently failing and blocking the security gate jobs. 2016-08-17 22:26:51.190872 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : Check for AIDE cron job (for V-38670)] *** 2016-08-17 22:26:51.327211 | ok: [localhost] 2016-08-17 22:26:51.334723 | 2016-08-17 22:26:51.334789 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : V-38670 - System must detect unauthorized changes to software and information] *** 2016-08-17 22:26:51.381252 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "AIDE cron job is missing"} 2016-08-17 22:26:51.387073 | 2016-08-17 22:26:51.387128 | msg: AIDE cron job is missing 2016-08-17 22:26:51.387140 | 2016-08-17 22:26:51.387155 | msg: AIDE cron job is missing The aide package installs properly, but there is no cron job file found within the package. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1614532/+subscriptions From 1613199 at bugs.launchpad.net Thu Aug 18 19:17:48 2016 From: 1613199 at bugs.launchpad.net (Augustina Ragwitz) Date: Thu, 18 Aug 2016 19:17:48 -0000 Subject: [Openstack-security] [Bug 1613199] Re: nova does not accept ssh certificate authorities (regression) References: <20160815075845.16694.60193.malonedeb@chaenomeles.canonical.com> Message-ID: <20160818191750.16512.87156.launchpad@chaenomeles.canonical.com> ** Changed in: nova Importance: High => Undecided -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1613199 Title: nova does not accept ssh certificate authorities (regression) Status in OpenStack Compute (nova): Confirmed Bug description: Prior to commit 3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a nova/crypto.py generate_fingerprint used ssh-keygen -q -l -f to generate finger prints. ssh-keygen -qlf is quite happy to process public key matter of the form cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun The issue is the string cert-authority at the beginning of the public key matter. This form can appear in authorized_keys to enable multiple users on a project to have individual keys certified by a central certifying authority providing access to a single administrative account. The use of ssh certificates is documented here: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh- ca-to-validate-hosts-and-clients-with-ubuntu Steps to reproduce: 1) Place the string """ cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun """ in a file 2) run nova keypair-add --pub-key Expected result: They nova keypair-list should now list the key Actual result: ERROR (BadRequest): Keypair data is invalid: failed to generate fingerprint (HTTP 400) Environment: Openstack liberty release (bug is not present on kilo) Logs: Sorry, not available (I'm only a user not an admin) Suggest fix: either: 1) revert generate_fingerprint to using exec ssh-keygen 2) generate_fingerprint should strip the string cert-authority from the begining of the public key matter (if present) before attempting to generate the fingerprint. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1613199/+subscriptions From 1613199 at bugs.launchpad.net Thu Aug 18 19:36:45 2016 From: 1613199 at bugs.launchpad.net (Augustina Ragwitz) Date: Thu, 18 Aug 2016 19:36:45 -0000 Subject: [Openstack-security] [Bug 1613199] Re: nova does not accept ssh certificate authorities (regression) References: <20160815075845.16694.60193.malonedeb@chaenomeles.canonical.com> Message-ID: <20160818193647.17026.75.launchpad@chaenomeles.canonical.com> ** 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/1613199 Title: nova does not accept ssh certificate authorities (regression) Status in OpenStack Compute (nova): Incomplete Bug description: Prior to commit 3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a nova/crypto.py generate_fingerprint used ssh-keygen -q -l -f to generate finger prints. ssh-keygen -qlf is quite happy to process public key matter of the form cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun The issue is the string cert-authority at the beginning of the public key matter. This form can appear in authorized_keys to enable multiple users on a project to have individual keys certified by a central certifying authority providing access to a single administrative account. The use of ssh certificates is documented here: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh- ca-to-validate-hosts-and-clients-with-ubuntu Steps to reproduce: 1) Place the string """ cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun """ in a file 2) run nova keypair-add --pub-key Expected result: They nova keypair-list should now list the key Actual result: ERROR (BadRequest): Keypair data is invalid: failed to generate fingerprint (HTTP 400) Environment: Openstack liberty release (bug is not present on kilo) Logs: Sorry, not available (I'm only a user not an admin) Suggest fix: either: 1) revert generate_fingerprint to using exec ssh-keygen 2) generate_fingerprint should strip the string cert-authority from the begining of the public key matter (if present) before attempting to generate the fingerprint. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1613199/+subscriptions From 1613199 at bugs.launchpad.net Thu Aug 18 19:43:42 2016 From: 1613199 at bugs.launchpad.net (Augustina Ragwitz) Date: Thu, 18 Aug 2016 19:43:42 -0000 Subject: [Openstack-security] [Bug 1613199] Re: nova does not accept ssh certificate authorities (regression) References: <20160815075845.16694.60193.malonedeb@chaenomeles.canonical.com> Message-ID: <20160818194342.29023.95235.malone@wampee.canonical.com> First off, apologies, when I first glanced at your bug I initially thought you were reporting an issue with Nova not accepting valid public key files. Upon further investigation, I attempted to follow your reproduction steps by adding a public key generated by a certificate authority and did not experience the error. When I looked at that public key file, it did not have the prefix "cert-authority". Upon further investigation, it looks like these libraries are working as expected for the key files formatted per RFC 4253: https://tools.ietf.org/html/rfc4253#section-6.6. So the big question I have for you is what exactly is your workflow for generating the public key that you are trying to add to nova? ** Tags removed: liberty-backport-potential security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1613199 Title: nova does not accept ssh certificate authorities (regression) Status in OpenStack Compute (nova): Incomplete Bug description: Prior to commit 3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a nova/crypto.py generate_fingerprint used ssh-keygen -q -l -f to generate finger prints. ssh-keygen -qlf is quite happy to process public key matter of the form cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun The issue is the string cert-authority at the beginning of the public key matter. This form can appear in authorized_keys to enable multiple users on a project to have individual keys certified by a central certifying authority providing access to a single administrative account. The use of ssh certificates is documented here: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh- ca-to-validate-hosts-and-clients-with-ubuntu Steps to reproduce: 1) Place the string """ cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfHlWGrnpirvqvUTySnoQK6ze5oIXz7cYIT+XCBeBCahlK05O38g0erBGrNWFozZwbIXnysVCibaUJqtH0JrYqmcr2NnYA0PoiTeranvaJI7pQsga1gBxfK/D4UItw5yI6V7w9efMT0zpIP8WEubQz6GFtkyiNVgFCHj3+VhLs3RslvYzb35SFcLXEDsGVQM5NdWBUgRaNRqpTPvuMcxTyPvy32wW72kwaYRQioDJFcE2WJ240M2oSsx+dhTWvI8sW1sEUI1qIDfyBPsOgsLofuSpt4ZNgJqBUTp/hW85wVpNzud6A4YJWHpZXSDMtUMYE9QL+x2fw/b26yck9ZPE/ hines at tun """ in a file 2) run nova keypair-add --pub-key Expected result: They nova keypair-list should now list the key Actual result: ERROR (BadRequest): Keypair data is invalid: failed to generate fingerprint (HTTP 400) Environment: Openstack liberty release (bug is not present on kilo) Logs: Sorry, not available (I'm only a user not an admin) Suggest fix: either: 1) revert generate_fingerprint to using exec ssh-keygen 2) generate_fingerprint should strip the string cert-authority from the begining of the public key matter (if present) before attempting to generate the fingerprint. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1613199/+subscriptions From 1614532 at bugs.launchpad.net Fri Aug 19 14:03:46 2016 From: 1614532 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 19 Aug 2016 14:03:46 -0000 Subject: [Openstack-security] [Bug 1614532] Re: V-38670 aide cron job checks fails References: <20160818133053.29908.84729.malonedeb@gac.canonical.com> Message-ID: <20160819140346.9738.58729.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/357278 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=822ffad0bc666fba813048abb38e2ea775309e17 Submitter: Jenkins Branch: master commit 822ffad0bc666fba813048abb38e2ea775309e17 Author: Major Hayden Date: Thu Aug 18 10:08:13 2016 -0500 Add AIDE cron job in CentOS 7 This patch ensures that the AIDE cron job is present on CentOS 7 and RHEL 7 servers. Closes-bug: 1614532 Change-Id: I4ce25cb4fcfffcadf5c19fef429488f5f9d8aa8f ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1614532 Title: V-38670 aide cron job checks fails Status in openstack-ansible: Fix Released Bug description: The cron job check for aide's cron job in V-38670 is currently failing and blocking the security gate jobs. 2016-08-17 22:26:51.190872 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : Check for AIDE cron job (for V-38670)] *** 2016-08-17 22:26:51.327211 | ok: [localhost] 2016-08-17 22:26:51.334723 | 2016-08-17 22:26:51.334789 | TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : V-38670 - System must detect unauthorized changes to software and information] *** 2016-08-17 22:26:51.381252 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "AIDE cron job is missing"} 2016-08-17 22:26:51.387073 | 2016-08-17 22:26:51.387128 | msg: AIDE cron job is missing 2016-08-17 22:26:51.387140 | 2016-08-17 22:26:51.387155 | msg: AIDE cron job is missing The aide package installs properly, but there is no cron job file found within the package. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1614532/+subscriptions From gerrit2 at review.openstack.org Tue Aug 23 00:05:47 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 23 Aug 2016 00:05:47 +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 8a56773a9b0e1f79bb58bb3d8c36261b7ee7cacf 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. Added details around plugin name and how its used in secret_stores 'name' field. Added changes related to how multiple plugin configuration is going to be specified and used. Added field to capture crypto_plugin name in addition to secret store plugin name. This is done as both software only and pkcs11 plugin uses database (store_crypto) as storage backend. Difference is in crypto plugin used (simple crypto vs p11_crypto). APIImpact SecurityImpact Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba From 1612688 at bugs.launchpad.net Tue Aug 23 16:50:28 2016 From: 1612688 at bugs.launchpad.net (Jean-Philippe Evrard) Date: Tue, 23 Aug 2016 16:50:28 -0000 Subject: [Openstack-security] [Bug 1612688] Re: rpmverify check on auditd fails References: <20160812145702.22947.19301.malonedeb@soybean.canonical.com> Message-ID: <20160823165028.10936.31701.malone@soybean.canonical.com> This was fixed with the following review: https://review.openstack.org/#/c/354768/ ** Changed in: openstack-ansible Status: New => 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/1612688 Title: rpmverify check on auditd fails Status in openstack-ansible: Fix Released Bug description: The Ansible task for V-38637 fails because some additional configuration files have changed from the auditd package defaults. TASK [/home/jenkins/workspace/gate-openstack-ansible-security-ansible-func-centos-7 : V-38637 - Contents of auditd package must be verified] *** fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Could not verify that files from auditd package are unaltered"} To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1612688/+subscriptions From gerrit2 at review.openstack.org Tue Aug 23 17:56:01 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 23 Aug 2016 17:56:01 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Id2304adeb9490a630e1979bb70037ad8a2656d73 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357151 Log: commit f475bb5040e266907d8df68a88d9ed239c7d066f Author: Peter Hamilton Date: Thu Aug 18 07:45:50 2016 -0400 Add support for certificate validation This spec describes changes to the Cursive library that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of certificate trust store support in Cursive allows Nova admins to control which certificates are allowed to sign images used on their compute nodes. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 SecurityImpact DocImpact Change-Id: Id2304adeb9490a630e1979bb70037ad8a2656d73 From gerrit2 at review.openstack.org Tue Aug 23 18:24:52 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 23 Aug 2016 18:24:52 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit a42ba7b25580ffafbe0821601dc76303add625e2 Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 Add certificate validation This change adds support for a certificate trust store. When performing signature verification, all certificates in the trust store are loaded into a certificate verification context. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the trust store. The signature_utils.get_verifier function is updated to accept an additional, optional parameter: trust_store_path. This parameter should contain a valid filesystem path to the directory acting as the certificate trust store. If not provided, it defaults to None and the trust store will be considered empty. All new certificate utility code is added in a new module named certificate_utils. For more information on this work, see the spec: https://review.openstack.org/#/c/357151/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b From major at mhtx.net Wed Aug 24 02:30:02 2016 From: major at mhtx.net (Major Hayden) Date: Wed, 24 Aug 2016 02:30:02 -0000 Subject: [Openstack-security] [Bug 1616281] [NEW] Can't initialize AIDE during subsequent playbook runs Message-ID: <20160824023003.4754.11744.malonedeb@gac.canonical.com> Public bug reported: AIDE isn't initialized by default because it can cause a lot of system load when it does its first check of a new system. If a deployer applies the security hardening role with ``initialize_aide`` set to False (the default), it won't be initialized. However, if they set it to True and re-run the playbook, AIDE is already configured and the handler to initialize AIDE won't execute. ** Affects: openstack-ansible Importance: Medium Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1616281 Title: Can't initialize AIDE during subsequent playbook runs Status in openstack-ansible: New Bug description: AIDE isn't initialized by default because it can cause a lot of system load when it does its first check of a new system. If a deployer applies the security hardening role with ``initialize_aide`` set to False (the default), it won't be initialized. However, if they set it to True and re-run the playbook, AIDE is already configured and the handler to initialize AIDE won't execute. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1616281/+subscriptions From 1616281 at bugs.launchpad.net Wed Aug 24 02:53:21 2016 From: 1616281 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 24 Aug 2016 02:53:21 -0000 Subject: [Openstack-security] [Bug 1616281] Re: Can't initialize AIDE during subsequent playbook runs References: <20160824023003.4754.11744.malonedeb@gac.canonical.com> Message-ID: <20160824025321.22214.27433.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/359554 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1616281 Title: Can't initialize AIDE during subsequent playbook runs Status in openstack-ansible: In Progress Bug description: AIDE isn't initialized by default because it can cause a lot of system load when it does its first check of a new system. If a deployer applies the security hardening role with ``initialize_aide`` set to False (the default), it won't be initialized. However, if they set it to True and re-run the playbook, AIDE is already configured and the handler to initialize AIDE won't execute. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1616281/+subscriptions From gerrit2 at review.openstack.org Wed Aug 24 12:28:40 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 24 Aug 2016 12:28:40 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Id2304adeb9490a630e1979bb70037ad8a2656d73 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357151 Log: commit 979eb09f28cae1c688999cd3dfc71ebc899514af Author: Peter Hamilton Date: Thu Aug 18 07:45:50 2016 -0400 Add support for certificate validation This spec describes changes to the Cursive library that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of certificate trust store support in Cursive allows Nova admins to control which certificates are allowed to sign images used on their compute nodes. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 SecurityImpact DocImpact Change-Id: Id2304adeb9490a630e1979bb70037ad8a2656d73 From major at mhtx.net Wed Aug 24 20:58:51 2016 From: major at mhtx.net (Major Hayden) Date: Wed, 24 Aug 2016 20:58:51 -0000 Subject: [Openstack-security] [Bug 1590185] Re: "V-38496 - Gather problematic system accounts" check fails on RHEL 7 References: <20160607232139.12031.65314.malonedeb@wampee.canonical.com> Message-ID: <20160824205852.3211.77722.launchpad@gac.canonical.com> ** Changed in: openstack-ansible 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/1590185 Title: "V-38496 - Gather problematic system accounts" check fails on RHEL 7 Status in openstack-ansible: Incomplete Bug description: The check "V-38496 - Gather problematic system accounts" fails gloriously due to RHEL 7 not using jinja2.8 by default. The specific issue is due to Jinja being 2.7 and not 2.8. If see the following error then you need to run "pip install Jinja2 --upgrade": TASK: [openstack-ansible-security | V-38496 - Gather problematic system accounts] *** fatal: [172.31.255.20] => Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 586, in _executor exec_rc = self._executor_internal(host, new_stdin) File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 789, in _executor_internal return self._executor_internal_inner(host, self.module_name, self.module_args, inject, port, complex_args=complex_args) File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 1013, in _executor_internal_inner complex_args = template.template(self.basedir, complex_args, inject, fail_on_undefined=self.error_on_undefined_vars) File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 140, in template d[k] = template(basedir, v, templatevars, lookup_fatal, depth, expand_lists, convert_bare, fail_on_undefined, filter_fatal) File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 124, in template varname = template_from_string(basedir, varname, templatevars, fail_on_undefined) File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 382, in template_from_string res = jinja2.utils.concat(rf) File "