From f02609813e227a4d65d2b45f12d7cec5347e8a14 Mon Sep 17 00:00:00 2001 From: Nathan Kinder Date: Wed, 12 Feb 2014 21:35:18 -0800 Subject: [PATCH] Add previously published security notes This adds all previously published security notes to the repo. I also provided some helpful documentation in the README and provided e-mail and wiki format templates to aid in writing new security notes. --- README.md | 30 +++++++++++++++-- notes/OSSN-0001 | 46 ++++++++++++++++++++++++++ notes/OSSN-0002 | 36 +++++++++++++++++++++ notes/OSSN-0003 | 44 +++++++++++++++++++++++++ notes/OSSN-0004 | 60 ++++++++++++++++++++++++++++++++++ notes/OSSN-0005 | 54 +++++++++++++++++++++++++++++++ notes/OSSN-0006 | 63 ++++++++++++++++++++++++++++++++++++ templates/email-template.txt | 26 +++++++++++++++ templates/wiki-template.txt | 26 +++++++++++++++ 9 files changed, 382 insertions(+), 3 deletions(-) create mode 100644 notes/OSSN-0001 create mode 100644 notes/OSSN-0002 create mode 100644 notes/OSSN-0003 create mode 100644 notes/OSSN-0004 create mode 100644 notes/OSSN-0005 create mode 100644 notes/OSSN-0006 create mode 100644 templates/email-template.txt create mode 100644 templates/wiki-template.txt diff --git a/README.md b/README.md index 30fe269..d91ed58 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,28 @@ -security-notes -============== - OpenStack Security Notes (OSSN) +=============================== + +The OpenStack Security Group (OSSG) publishes Security Notes to advise users +of security related issues. Security notes are similar to advisories; they +address vulnerabilities in 3rd party tools typically used within OpenStack +deployments and provide guidance on common configuration mistakes that can +result in an insecure operating environment. + +Repository Layout +----------------- + +This repository contains published Security Notes and templates that should +be used when creating new Security Notes. + + notes - contains Security Notes in e-mail format (see the templates) + templates - contains e-mail and wiki format templates + +Useful Links +------------ + +A list of published Security Notes is available here: + + https://wiki.openstack.org/wiki/Security_Notes + +The process used to create new Security Notes is available here: + + https://wiki.openstack.org/wiki/Security/Security_Note_Process diff --git a/notes/OSSN-0001 b/notes/OSSN-0001 new file mode 100644 index 0000000..fa3cdd6 --- /dev/null +++ b/notes/OSSN-0001 @@ -0,0 +1,46 @@ +Selecting LXC as Nova Virtualization Driver can lead to data compromise +--- + +### Summary### +LXC does not provide the same level of separation as hypervisors when chosen as +the Nova 'virtualization driver'. Attempting to use LXC as a drop in +replacement for a hypervisor can result in data exposure between tenants. + +### Affected Services / Software ### +Nova, LXC, Libvirt, 'Virtualization Driver' + +### Discussion ### +The Libvirt LXC functionality exposed by OpenStack is built on the kernel +namespace & cgroup technologies. Until Linux 3.8, there has been no support for +separate user namespaces in the kernel. As such, there has been no way to +securely isolate containers from each other or the host environment using DAC +(discretionary access control). For example, they can escape their resource +constraints by modifying cgroups settings, or attack the host via various files +in the proc and sysfs filesystems. The use of MAC (mandatory access control) +technologies like SELinux or AppArmour can mitigate these problems, but it is +not practical to write MAC policies that would allow running full OS installs +in LXC under OpenStack. + +Although initial user namespace support was merged in Linux 3.8, it is not yet +complete, or mature enough to be considered secure. Work is ongoing to finish +the kernel namespace support and enhance libvirt LXC to take advantage of it. + +### Recommended Actions ### +The OSSG advises that anyone deploying Nova in environments that require any +level of separation use a hypervisor such as Xen, KVM, VMware or Hyper-V. + +LXC security pivots on a system known as DAC (discretionary access control) +which is not currently capable of providing strong isolation of guests. Work is +underway to improve DAC but it’s not ready for production use at this time. + +The OSSG recommends against using LXC for enforcing secure separation of guests. +Even with appropriate AppArmour policies applied. + +### Contacts / References ### +Nova : http://docs.openstack.org/developer/nova/ +LXC : http://lxc.sourceforge.net/ +Libvirt : http://libvirt.org/ +KVM : http://www.linux-kvm.org/page/Main_Page +Xen: http://xen.org/products/xenhyp.html +LXC DAC : https://wiki.ubuntu.com/UserNamespace +LXC LibVirt Discussion : https://www.berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/ diff --git a/notes/OSSN-0002 b/notes/OSSN-0002 new file mode 100644 index 0000000..cd7f77e --- /dev/null +++ b/notes/OSSN-0002 @@ -0,0 +1,36 @@ +HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS +--- + +### Summary ### +Concurrent Keystone POST requests with large body messages are held in memory +without filtering or rate limiting, this can lead to resource exhaustion on the +Keystone server. + +### Affected Services / Software ### +Keystone, Databases + +### Discussion ### +Keystone stores POST messages in memory before validation, concurrent +submission of multiple large POST messages can cause the Keystone process to be +killed due to memory exhaustion, resulting in a remote Denial of Service. + +In many cases Keystone will be deployed behind a load-balancer or proxy that +can rate limit POST messages inbound to Keystone. Grizzly is protected +against that through the sizelimit middleware. + +### Recommended Actions ### +If you are in a situation where Keystone is directly exposed to incoming POST +messages and not protected by the sizelimit middleware there are a number of +load-balancing/proxy options, we suggest you consider one of the following: + +Nginx: Open-source, high-performance HTTP server and reverse proxy. +Nginx Config: http://wiki.nginx.org/HttpCoreModule#client_max_body_size + +Apache: HTTP Server Project +Apache Config: http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody + +### Contacts / References ### +This OSSN Bug: https://bugs.launchpad.net/ossn/+bug/1155566 +Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1098177 +OpenStack Security ML : openstack-security@lists.openstack.org +OpenStack Security Group : https://launchpad.net/~openstack-ossg diff --git a/notes/OSSN-0003 b/notes/OSSN-0003 new file mode 100644 index 0000000..fe2542c --- /dev/null +++ b/notes/OSSN-0003 @@ -0,0 +1,44 @@ +Keystone configuration should not be world readable +--- + +### Summary ### +In some deployments keystone.conf which contains confidential information, is +set to world readable. + +### Affected Services / Software ### +Keystone, DevStack, Deployment + +### Discussion ### +It is important that deployers of OpenStack ensure that keystone.conf is not +world readable. In some deployments the keystone configuration file is readable +by all users (and processes) on the installation system. This file should be +set with the most restrictive permissions that allow the system to continue +proper operations. + +In particular, the password configuration of the LDAP section and the +admin_token contain secret information: + +---- being example config snippet ---- +[ldap] +url = ldap://localhost +user = dc=Manager,dc=example,dc=com +password = None <- should be secret +suffix = cn=example,cn=com +use_dumb_member = False +allow_subtree_delete = False +dumb_member = cn=dumb,dc=example,dc=com + +[DEFAULT] +admin_token = passw0rd <- should be secret +---- end example config snippet ---- + +### Recommended Actions ### +Ensure that in your deployment keystone.conf uses the most restrictive +permissions that allow the system to continue proper operations. + +### Contacts / References ### +This OSSN : https://bugs.launchpad.net/ossn/+bug/1168252 +Original LaunchPad Bug : https://bugs.launchpad.net/devstack/+bug/1168252 +OpenStack Security ML : openstack-security@lists.openstack.org +OpenStack Security Group : https://launchpad.net/~openstack-ossg +CVE: CVE-2013-1977 diff --git a/notes/OSSN-0004 b/notes/OSSN-0004 new file mode 100644 index 0000000..a2dbda1 --- /dev/null +++ b/notes/OSSN-0004 @@ -0,0 +1,60 @@ +Authenticated users are able to update passwords without providing their +current password +--- + +### Summary ### +An authenticated user is able to change their password without providing their +current password. This allows compromised authentication tokens to be used to +permanently compromise a user account. + +### Affected Services / Software ### +Horizon, Keystone, Identity, Grizzly + +### Discussion ### +Horizon allows a user to change their own password, which uses the Identity API +to perform the password change. A user is required to supply their current +password to successfully perform a password change. This requirement prevents a +malicious user from stealing a user's authentication token and changing that +user's password to permanently compromise their account. With this additional +password check, a compromised authentication token only compromises the user +account until the token is no longer valid due to expiration or revocation. + +When using the Identity v3 API, a user is able to successfully change their +password without supplying the correct current password. This leaves users +vulnerable to permanently compromised accounts if their authentication token is +compromised. The Identity v2 API is not vulnerable to this issue, as it has a +separate API call for updating user passwords that properly validates the +current password. + +### Recommended Actions ### +In the OpenStack Grizzly release, a user is allowed to update the attributes in +their own entry by default. It is recommended that you restrict user updates to +only be allowed by admin users. This is done by setting the "update_user" +policy to "admin_required" in Keystone's policy.json file. Here is an example +snippet of a properly configured policy.json file: + +---- begin example policy.json snippet ---- + "identity:get_user": [["rule:admin_required"]], + "identity:list_users": [["rule:admin_required"]], + "identity:create_user": [["rule:admin_required"]], + "identity:update_user": [["rule:admin_required"]], + "identity:delete_user": [["rule:admin_required"]], +---- end example policy.json snippet ---- + +This change has the side-effect of restricting a user from updating any of +their own attributes, not just their password. + +In the OpenStack Havana release, the default policy is to only allow admin +users to update attributes in user entries. In addition, Horizon will not +allow a user to change their own password if it is using the Identity v3 API, +even if Keystone is configured to allow users to update their own entries. +Despite this restriction in Horizon, it is recommended to leave the default +"update_user" policy setting as is, as an attacker could target Keystone +directly without using Horizon to initiate a password change. + +### Contacts / References ### +This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989 +Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989 +OpenStack Security ML : openstack-security@lists.openstack.org +OpenStack Security Group : https://launchpad.net/~openstack-ossg +CVE: CVE-2013-4471 diff --git a/notes/OSSN-0005 b/notes/OSSN-0005 new file mode 100644 index 0000000..be4c410 --- /dev/null +++ b/notes/OSSN-0005 @@ -0,0 +1,54 @@ +Glance allows sharing of images between projects without consumer project +approval +--- + +### Summary ### +Glance allows images to be shared between projects. In certain API versions, +images can be shared without the consumer project's approval. This allows +potentially malicious images to show up in a project's image list. + +### Affected Services / Software ### +Glance, Image Service, Diablo, Essex, Folsom, Grizzly, Havana + +### Discussion ### +Since the OpenStack Diablo release, Glance allows images to be shared between +projects. To share an image, the producer of the image adds the consumer +project as a member of the image. When using the Image Service API v1, the +image producer is able to share an image with a consumer project without their +approval. This results in the shared image showing up in the image list for the +consumer project. This can mislead users with roles in the consumer project +into running a potentially malicious image. + +The Image Service API v2.0 does not allow image sharing between projects, so a +project is not susceptible to running unauthorized images shared by other +projects. The Image Service API v2.1 allows image sharing using a two-step +process. An image producer must add a consumer as a member of the image, and +the consumer must accept the shared image before it shows up in their image +list. This additional approval process allows a consumer to control what images +show up in their image list, thus preventing potentially malicious images being +used without the consumers knowledge. + +### Recommended Actions ### +In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image +sharing using the Image Service API v1. There is no way to require approval of +a shared image by consumer projects. Users should be cautioned to be careful +when using images from their image list, as they may be using an image that was +shared with them without their knowledge. + +In the OpenStack Grizzly and Havana releases, Glance supports the Image Service +API v2.1 or later. Support is still provided for Image Service API v1, which +allows image sharing between projects without consumer project approval. It is +recommended to disable v1 of the Image Service API if possible. This can be +done by setting the following directive in the glance-api.conf configuration +file: + +---- begin example glance-api.conf snippet ---- +enable_v1_api = False +---- end example glance-api.conf snippet ---- + +### Contacts / References ### +This OSSN : https://bugs.launchpad.net/ossn/+bug/1226078 +Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1226078 +OpenStack Security ML : openstack-security@lists.openstack.org +OpenStack Security Group : https://launchpad.net/~openstack-ossg +CVE: CVE-2013-4354 diff --git a/notes/OSSN-0006 b/notes/OSSN-0006 new file mode 100644 index 0000000..c9618b5 --- /dev/null +++ b/notes/OSSN-0006 @@ -0,0 +1,63 @@ +Keystone can allow user impersonation when using REMOTE_USER for external +authentication +--- + +### Summary ### +When external authentication is used with Keystone using the "ExternalDefault" +plug-in, external usernames containing "@" characters are truncated at the "@" +character before being mapped to a local Keystone user. This can result in +separate external users mapping to the same local Keystone user, which could +lead to user impersonation. + +### Affected Services / Software ### +Keystone, Havana + +### Discussion ### +When Keystone is run in the Apache HTTP Server, the webserver can handle +authentication and pass the authenticated username to Keystone using the +REMOTE_USER environment variable. External authentication behavior is handled +by authentication plugins in Keystone. In the Havana release of OpenStack, if +the external username provided in the REMOTE_USER environment variable +contains an "@" character Keystone will only use the portion preceding the "@" +character as the username when using the "ExternalDefault" authentication +plugin. This results in the ability for multiple unique external usernames to +map to the same single username in Keystone. For example, the external +usernames "jdoe@example1.com" and "jdoe@example2.com" would both map to the +Keystone user "jdoe". This behavior could potentially be abused to allow one to +impersonate another similarly named external user. + +Keystone in OpenStack releases prior to Havana uses the entire value contained +in the REMOTE_USER environment variable, so those versions are not vulnerable +to this impersonation issue. + +### Recommended Actions ### +If the "ExternalDefault" plugin is being used for external authentication in +the Havana release, you should ensure that external usernames do not contain +"@" characters unless you want to collapse similarly named external users into +a single user on the Keystone side. + +If your external usernames do contain "@" characters and you do not want to +collapse similarly named external users into a single user on the Keystone +side, you might be able to use the "ExternalDomain" plug-in. This plugin +considers the portion of the external username that follows an "@" character to +be the domain that the user belongs to in Keystone. This allows similarly named +external users to map to separate Keystone users if the portion of the external +username that follows an "@" character maps to a Keystone domain name. To +configure the "ExternalDomain" authentication plugin, set the "external" +parameter in the "[auth]" section of Keystone's keystone.conf as follows: + +---- begin example keystone.conf snippet ---- +[auth] +methods = external,password,token +external = keystone.auth.plugins.external.ExternalDomain +---- end example keystone.conf snippet ---- + +If neither of the above recommendations work for your deployment, a custom +authentication plugin can be created that uses the external username that +contains an "@" character as-is. + +### Contacts / References ### +This OSSN : https://bugs.launchpad.net/ossn/+bug/1254619 +Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1254619 +OpenStack Security ML : openstack-security@lists.openstack.org +OpenStack Security Group : https://launchpad.net/~openstack-ossg diff --git a/templates/email-template.txt b/templates/email-template.txt new file mode 100644 index 0000000..d507389 --- /dev/null +++ b/templates/email-template.txt @@ -0,0 +1,26 @@ +Title (single sentence) +--- + +### Summary ### +A few sentences describing the issue at a high level. + +### Affected Services / Software ### +A comma separated list of affected services and OpenStack releases. + +### Discussion ### +A detailed discussion of the problem. This should have enough detail that the +person reading can determine if their deployment is affected, when the problem +was introduced, and what types of attacks/problems that an affected deployment +would be exposed to. + +### Recommended Actions ### +A detailed description of what can be done to remediate the problem (if +possible). If the recommendation involves configuration changes, example +snippets of configuration files should be included here. + +### Contacts / References ### +This OSSN : +Original LaunchPad Bug : +OpenStack Security ML : openstack-security@lists.openstack.org +OpenStack Security Group : https://launchpad.net/~openstack-ossg +CVE: diff --git a/templates/wiki-template.txt b/templates/wiki-template.txt new file mode 100644 index 0000000..bbb81a2 --- /dev/null +++ b/templates/wiki-template.txt @@ -0,0 +1,26 @@ +__NOTOC__ +== Title (single sentence) == + +=== Summary === +A few sentences describing the issue at a high level. + +=== Affected Services / Software === +A comma separated list of affected services and OpenStack releases. + +=== Discussion === +A detailed discussion of the problem. This should have enough detail that the +person reading can determine if their deployment is affected, when the problem +was introduced, and what types of attacks/problems that an affected deployment +would be exposed to. + +=== Recommended Actions === +A detailed description of what can be done to remediate the problem (if +possible). If the recommendation involves configuration changes, example +snippets of configuration files should be included here. + +=== Contacts / References === +* This OSSN : +* Original LaunchPad Bug : +* OpenStack Security ML : openstack-security@lists.openstack.org +* OpenStack Security Group : https://launchpad.net/~openstack-ossg +* CVE: