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)
|
||||
===============================
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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>
|
||||
|
|
@ -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…
Reference in New Issue