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.
This commit is contained in:
Nathan Kinder
parent
e5125edcbd
commit
f02609813e
30
README.md
30
README.md
@ -1,4 +1,28 @@
|
|||||||
security-notes
|
|
||||||
==============
|
|
||||||
|
|
||||||
OpenStack Security Notes (OSSN)
|
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
46
notes/OSSN-0001
Normal 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
36
notes/OSSN-0002
Normal 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
44
notes/OSSN-0003
Normal 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
60
notes/OSSN-0004
Normal 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
54
notes/OSSN-0005
Normal 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
63
notes/OSSN-0006
Normal 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
26
templates/email-template.txt
Normal 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
26
templates/wiki-template.txt
Normal 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>
|
||||||
Loading…
x
Reference in New Issue
Block a user