openstack-attic/openstack-security-notes
Code Issues Proposed changes

Add previously published security notes

Browse Source 
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.
This commit is contained in:
Nathan Kinder 2014-02-12 21:35:18 -08:00
parent e5125edcbd
commit f02609813e
9 changed files with 382 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
README.md
View File

@ -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

46
notes/OSSN-0001 Normal file
View File

@ -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/

36
notes/OSSN-0002 Normal file
View File

@ -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

44
notes/OSSN-0003 Normal file
View File

@ -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

60
notes/OSSN-0004 Normal file
View File

@ -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

54
notes/OSSN-0005 Normal file
View File

@ -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

63
notes/OSSN-0006 Normal file
View File

@ -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

26
templates/email-template.txt Normal file
View File

@ -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 : <link to launchpad OSSN bug>
Original LaunchPad Bug : <link to launchpad bug for affected project/service>
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: <CVE number if one was filed>

26
templates/wiki-template.txt Normal file
View File

@ -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 :<link to launchpad OSSN bug>
* Original LaunchPad Bug : <link to launchpad bug for affected project/service>
* OpenStack Security ML : openstack-security@lists.openstack.org
* OpenStack Security Group : https://launchpad.net/~openstack-ossg
* CVE: <CVE number if one was filed>