openstack/security-doc
Code Issues Proposed changes

Migrate OSSNs to the security-doc repo

Browse Source 
The OpenStack Security Notes are being migrated to the new
security-doc repository that we use for the security guide.  This
patch migrates over the existing content of the old OSSN repository
without any modification to content.

Change-Id: I348d0591fc71c1174368fad7ef761e489c88ab9c
This commit is contained in:
Nathan Kinder 2014-07-24 17:44:21 -07:00
parent 0becd2d601
commit 67b5ec2943
23 changed files with 1529 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
security-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
security-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
security-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
security-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
security-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
security-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

214
security-notes/OSSN-0007 Normal file
View File

@ -0,0 +1,214 @@
Live migration instructions recommend unsecured libvirt remote access
---
### Summary ###
When using the KVM hypervisor with libvirt on OpenStack Compute nodes,
live migration of instances from one Compute server to another requires
that the libvirt daemon is configured for remote network connectivity.
The libvirt daemon configuration recommended in the OpenStack
Configuration Reference manual configures libvirtd to listen for
incoming TCP connections on all network interfaces without requiring any
authentication or using any encryption. This insecure configuration
allows for anyone with network access to the libvirt daemon TCP port on
OpenStack Compute nodes to control the hypervisor through the libvirt
API.
### Affected Services / Software ###
Nova, Compute, KVM, libvirt, Grizzly, Havana, Icehouse
### Discussion ###
The default configuration of the libvirt daemon is to not allow remote
access. Live migration of running instances between OpenStack Compute
nodes requires libvirt daemon remote access between OpenStack Compute
nodes.
The libvirt daemon should not be configured to allow unauthenticated
remote access. The libvirt daemon has a choice of 4 secure options for
remote access over TCP. These options are:
- SSH tunnel to libvirtd's UNIX socket
- libvirtd TCP socket, with GSSAPI/Kerberos for auth+data encryption
- libvirtd TCP socket, with TLS for encryption and x.509 client
certificates for authentication
- libvirtd TCP socket, with TLS for encryption and Kerberos for
authentication
It is not necessary for the libvirt daemon to listen for remote TCP
connections on all interfaces. Remote network connectivity to the
libvirt daemon should be restricted as much as possible. Remote
access is only needed between the OpenStack Compute nodes, so the
libvirt daemon only needs to listen for remote TCP connections on the
interface that is used for this communication. A firewall can be
configured to lock down access to the TCP port that the libvirt daemon
listens on, but this does not sufficiently protect access to the libvirt
API. Other processes on a remote OpenStack Compute node might have
network access, but should not be authorized to remotely control the
hypervisor on another OpenStack Compute node.
### Recommended Actions ###
If you are using the KVM hypervisor with libvirt on OpenStack Compute
nodes, you should review your libvirt daemon configuration to ensure
that it is not allowing unauthenticated remote access.
Remote access to the libvirt daemon via TCP is configured by the
"listen_tls", "listen_tcp", and "auth_tcp" configuration directives. By
default, these directives are all commented out. This results in remote
access via TCP being disabled.
If you do not need remote libvirt daemon access, you should ensure that
the following configuration directives are set as follows in the
/etc/libvirt/libvirtd.conf configuration file. Commenting out these
directives will have the same effect, as these values match the internal
defaults:
---- begin example libvirtd.conf snippet ----
listen_tls = 1
listen_tcp = 0
auth_tcp = "sasl"
---- end example libvirtd.conf snippet ----
If you need to allow remote access to the libvirt daemon between
OpenStack Compute nodes for live migration, you should ensure that
authentication is required. Additionally, you should consider enabling
TLS to allow remote connections to be encrypted.
The following libvirt daemon configuration directives will allow for
unencrypted remote connections that use SASL for authentication:
---- begin example libvirtd.conf snippet ----
listen_tls = 0
listen_tcp = 1
auth_tcp = "sasl"
---- end example libvirtd.conf snippet ----
If you want to require TLS encrypted remote connections, you will have
to obtain X.509 certificates and configure the libvirt daemon to use
them to use TLS. Details on this configuration are in the libvirt
daemon documentation. Once the certificates are configured, you should
set the following libvirt daemon configuration directives:
---- begin example libvirtd.conf snippet ----
listen_tls = 1
listen_tcp = 0
auth_tls = "none"
---- end example libvirtd.conf snippet ----
When using TLS, setting the "auth_tls" configuration directive to "none"
uses X.509 client certificates for authentication. You can additionally
require SASL authentication by setting the following libvirt daemon
configuration directives:
---- begin example libvirtd.conf snippet ----
listen_tls = 1
listen_tcp = 0
auth_tls = "sasl"
---- end example libvirtd.conf snippet ----
When using TLS, it is also necessary to configure the OpenStack Compute
nodes to use a non-default URI for live migration. This is done by
setting the following configuration directive in /etc/nova/nova.conf:
---- begin example nova.conf snippet ----
live_migration_uri=qemu+tls://%s/system
---- end example nova.conf snippet ----
For more details on libvirt daemon remote URI formats, please see the
following libvirt daemon documentation:
http://libvirt.org/remote.html#Remote_URI_reference
For details on configuring SASL authentication and X.509 certificates
for the libvirt daemon, please consult the libvirt daemon documentation
at the following locations:
http://libvirt.org/remote.html
http://libvirt.org/auth.html
When configuring the libvirt daemon for authentication, it is also
important to configure authorization to restrict remote access to your
OpenStack Compute nodes. For example, if you don't configure
authorization, any X.509 client certificate that is signed by your
issuing CA will be allowed access. When using SASL/GSSAPI for Kerberos
authentication, any client with a valid TGT will be granted access.
Lack of authorization can allow unintended remote access. The libvirt
daemon documentation should be consulted for details on configuring
authorization.
In addition to requiring authentication for remote access to the libvirt
daemon on your OpenStack Compute nodes, it is also recommended to
restrict network access such that connectivity is only allowed between
the Compute nodes.
The first thing that should be done is to restrict the network
interfaces that the libvirt daemon listens on for remote connections.
By default, the libvirt daemon listens on all interfaces when remote
access is enabled. This can be restricted by setting the following
configuration directive in /etc/libvirt/libvirtd.conf:
---- begin example libvirtd.conf snippet ----
listen_addr = <IP address or hostname>
---- end example libvirtd.conf snippet ----
Migration in the libvirt daemon also uses a range of ephemeral ports by
default. The connections to these ephemeral ports are not authenticated
or encrypted. It is possible to tunnel the migration traffic over the
regular libvirt daemon remote access port, which will use the
authentication and encryption settings that you have defined for that
port. It is recommended that you do this for the additional security
that it provides. To enable tunnelling of the migration traffic, you
must tell your OpenStack Compute nodes to set the VIR_MIGRATE_TUNNELLED
flag for live migration. This is done by setting the following
directive in /etc/nova/nova.conf:
---- begin example nova.conf snippet ----
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER, VIR_MIGRATE_TUNNELLED
---- end example nova.conf snippet ----
The tunnelling of migration traffic described above does not apply to
live block migration. Live block migration is currently only possible
over ephemeral ports.
If you choose to use the ephemeral migration ports, there are a few
things that you should be aware of. Unfortunately, there is no way to
restrict the network interfaces that these ephemeral ports will listen
on in libvirt versions prior to 1.1.4. If you are running version 1.1.4
or later of the libvirt daemon, you can set the following directive in
/etc/libvirt/qemu.conf to specify what interfaces are used for the
ephemeral migration ports:
---- begin example qemu.conf snippet ----
migration_address = <IP address>
---- end example qemu.conf snippet ----
It is also recommended to configure the firewall on each OpenStack
Compute node to only allow other Compute nodes to access the ports that
are used for remote access to the libvirt daemon. By default, this is
port 16514 for TLS and 16509 for unencrypted TCP.
Additionally, migration over ephemeral ports uses a port range of
49152-49215. You will need to allow your OpenStack Compute nodes to
communicate with each other over these ports if you choose not to tunnel
the migration traffic over the libvirt daemon remote access port.
You can check what ports you have configured for the libvirt daemon by
looking at the following configuration directives:
tls_port (libvirtd.conf)
tcp_port (libvirtd.conf)
migration_port_min (qemu.conf)
migration_port_max (qemu.conf)
If you are running a version of the libvirt daemon older than 1.1.4 and
you want to perform live block migration, you will need to allow your
OpenStack Compute nodes to communicate over port range 5900-49151. If
you are running version 1.1.4 or later of the libvirt daemon, the
regular ephemeral migration port range is used for live block migration.
Please consult the documentation for your firewall software for
instructions on configuring the appropriate firewall rules.
### Contacts / References ###
This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0007
Original LaunchPad Bug : https://bugs.launchpad.net/openstack-manuals/+bug/1287194
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

49
security-notes/OSSN-0008 Normal file
View File

@ -0,0 +1,49 @@
DoS style attack on noVNC server can lead to service interruption or disruption
---
### Summary ###
There is currently no limit to the number of noVNC or SPICE console
sessions that can be established by a single user. The console host has
limited resources and an attacker launching many sessions may be able to
exhaust the available resources, resulting in a Denial of Service (DoS)
condition.
### Affected Services / Software ###
Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana
### Discussion ###
Currently with a single user token, no restrictions are enforced on the
number or frequency of noVNC or SPICE console sessions that may be
established. While a user can only access their own virtual machine
instances, resources can be exhausted on the console proxy host by
creating an excessive number of simultaneous console sessions. This can
result in timeouts for subsequent connection requests to instances using
the same console proxy. Not only would this prevent the user from
accessing their own instances, but other legitimate users would also be
deprived of console access. Further, other services running on the
noVNC proxy and Compute hosts may degrade in responsiveness.
By taking advantage of this lack of restrictions around noVNC or SPICE
console connections, a single user could cause the console proxy
endpoint to become unresponsive, resulting in a Denial Of Service (DoS)
style attack. It should be noted that there is no amplification effect.
### Recommended Actions ###
For current stable OpenStack releases (Grizzly, Havana), users need to
workaround this vulnerability by using rate-limiting proxies to cover
access to the noVNC proxy service. Rate-limiting is a common mechanism
to prevent DoS and Brute-Force attacks.
For example, if you are using a proxy such as Repose, enable the rate
limiting feature by following these steps:
https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter
Future OpenStack releases are looking to add the ability to restrict
noVNC and SPICE console connections.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

45
security-notes/OSSN-0009 Normal file
View File

@ -0,0 +1,45 @@
Potential token revocation abuse via group membership
---
### Summary ###
Deletion of groups in Keystone causes token revocation for group
members. If group capabilities are delegated to users, they can abuse
those capabilities to maliciously revoke tokens for other users.
### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse
### Discussion ###
If a group is deleted from Keystone, all tokens for all users that are
members of that group are revoked. By adding users to a group without
those users' knowledge and then deleting that group, a group admin can
revoke all of the users' tokens. While the default policy file gives
the group admin role to global admin, an alternative policy could
delegate the "create_group", "add_user_to_group", and "delete_group"
capabilities to a set of users. In such a system, those users will also
get a token revocation capability. Only setups using a custom policy
file in Keystone are affected.
### Recommended Actions ###
Keystone's default policy.json file uses the "admin_required" rule for
the "create_group", "delete_group", and "add_user_to_group"
capabilities. It is recommended that you use this default configuration
if possible. Here is an example snippet of a properly configured
policy.json file:
---- begin example policy.json snippet ----
"identity:create_group": "rule:admin_required",
"identity:delete_group": "rule:admin_required",
"identity:add_user_to_group": "rule:admin_required",
---- end example policy.json snippet ----
If you need to delegate the above capabilities to non-admin users, you
need to take into account that those users will be able to revoke
tokens for other users by performing group deletion operations. You
should take caution with who you delegate these capabilities to.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0009
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1268751
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

47
security-notes/OSSN-0010 Normal file
View File

@ -0,0 +1,47 @@
Sample Keystone v3 policy exposes privilege escalation vulnerability
---
### Summary ###
The policy.v3cloudsample.json sample Keystone policy file combined with
the underlying mutability of the domain ID for user, group, and project
entities exposed a privilege escalation vulnerability. When this
sample policy is applied a domain administrator can elevate their
privileges to become a cloud administrator.
### Affected Services / Software ###
Keystone, Havana
### Discussion ###
Changes to the Keystone v3 sample policy during the Havana release cycle
set an excessively broad domain administrator scope that allowed
creation of roles ("create_grant") on other domains (among other
actions). There was no check that the domain administrator had
authority to the domain they were attempting to grant a role on.
Combining the mutable state of the domain ID for user, group, and
project entities with the sample v3 policy resulted in a privilege
escalation vulnerability. A domain administrator could execute a series
of steps to escalate their access to that of a cloud administrator.
### Recommended Actions ###
Review the following updated sample v3 policy file from the OpenStack
Icehouse release:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=0496466821c1ff6e7d4209233b6c671f88aadc50
You should ensure that your Keystone deployment appropriately reflects
that update. Domain administrators should generally only be permitted
to perform actions against the domain for which they are an
administrator.
Optionally, review the recent addition of support for immutable domain
IDs and consider it for applicability to your Keystone deployment:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=a2fa6a6f01a4884edf369cafa39946636af5cf1a
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0010
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1287219
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

144
security-notes/OSSN-0011 Normal file
View File

@ -0,0 +1,144 @@
Heat templates with invalid references allows unintended network access
---
### Summary ###
Orchestration templates can create security groups to define network
access rules. When creating these rules, it is possible to have a rule
grant incoming network access to instances belonging to another security
group. If a rule references a non-existent security group, it can
result in allowing incoming access to all hosts for that rule.
### Affected Services / Software ###
Heat, nova-network, Havana
### Discussion ###
When defining security groups of the "AWS::EC2::SecurityGroup" type in a
CloudFormation-compatible format (CFN) orchestration template, it is
possible to use references to other security groups as the source for
ingress rules. When these rules are evaluated by Heat in the OpenStack
Havana release, a reference to a non-existent security group will be
silently ignored. This results in the rule using a "CidrIp" property of
"0.0.0.0/0". This will allow incoming access to any host for the
affected rule. This has the effect of allowing unintended network
access to instances.
This issue only occurs when Nova is used for networking (nova-network).
The Neutron networking service is not affected by this issue.
The OpenStack Icehouse release is not affected by this issue. In the
Icehouse release, Heat will check if a non-existent security group is
referenced in a template and return an error, causing the creation of
the security group to fail.
### Recommended Actions ###
If you are using Heat in the OpenStack Havana release with Nova for
networking (nova-network), you should review your orchestration
templates to ensure that all references to security groups in ingress
rules are valid. Specifically, you should look at the use of the
"SourceSecurityGroupName" property in your templates to ensure that
all referenced security groups exist.
One particular improper usage of security group references that you
should look for is the case where you define multiple security groups
in one template and use references between them. In this case, you
need to make sure that you are using the "Ref" intrinsic function to
indicate that you are referencing a security group that is defined in
the same template. Here is an example of a template with a valid
security group reference:
---- begin example correct template snippet ----
"WikiDatabaseSecurityGroup" : {
"Type" : "AWS::EC2::SecurityGroup",
"Properties" : {
"GroupDescription" : "Enable HTTP access plus SSH access",
"SecurityGroupIngress" : [
{
"IpProtocol" : "icmp",
"FromPort" : "-1",
"ToPort" : "-1",
"CidrIp" : "10.1.1.0/24"
},
{
"IpProtocol" : "tcp",
"FromPort" : "80",
"ToPort" : "80",
"CidrIp" : "10.1.1.0/24"
},
{
"IpProtocol" : "tcp",
"FromPort" : "22",
"ToPort" : "22",
"CidrIp" : "10.1.1.0/24"
},
{
"IpProtocol" : "tcp",
"FromPort" : "3306",
"ToPort" : "3306",
"SourceSecurityGroupName" : {
"Ref": "WebServerSecurityGroup"
}
}
]
}
},
"WebServerSecurityGroup" : {
"Type" : "AWS::EC2::SecurityGroup",
"Properties" : {
"GroupDescription" : "Enable HTTP access plus SSH access",
"SecurityGroupIngress" : [
{
"IpProtocol" : "icmp",
"FromPort" : "-1",
"ToPort" : "-1",
"CidrIp" : "10.1.1.0/24"
},
{
"IpProtocol" : "tcp",
"FromPort" : "80",
"ToPort" : "80",
"CidrIp" : "10.1.1.0/24"
},
{
"IpProtocol" : "tcp",
"FromPort" : "22",
"ToPort" : "22",
"CidrIp" : "10.1.1.0/24"
}
]
}
},
---- end example correct template snippet ----
Here is an example of an incorrect reference to a security group defined
in the same template:
---- begin example INVALID template snippet ----
{
"IpProtocol" : "tcp",
"FromPort" : "3306",
"ToPort" : "3306",
"SourceSecurityGroupName" : "WebServerSecurityGroup" #INCORRECT!
}
---- end example INVALID template snippet ----
The above invalid reference will result in allowing incoming networking
on port 3306 from all hosts:
IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-------------+--------------+
| icmp | -1 | -1 | 10.1.1.0/24 | |
| tcp | 80 | 80 | 10.1.1.0/24 | |
| tcp | 22 | 22 | 10.1.1.0/24 | |
| tcp | 3306 | 3306 | 0.0.0.0/0 | |
+-------------+-----------+---------+-------------+--------------+
It is also recommended that you test your templates if you are using
security group references to ensure that the resulting network rules
are as intended.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0011
Original LaunchPad Bug : https://bugs.launchpad.net/heat/+bug/1291091
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

73
security-notes/OSSN-0012 Normal file
View File

@ -0,0 +1,73 @@
OpenSSL Heartbleed vulnerability can lead to OpenStack compromise
---
### Summary ###
A vulnerability in OpenSSL can lead to leaking of confidential data
protected by SSL/TLS in an OpenStack deployment.
### Affected Services / Software ###
Grizzly, Havana, OpenSSL
### Discussion ###
A vulnerability in OpenSSL code-named Heartbleed was recently discovered
that allows remote attackers limited access to data in the memory of any
service using OpenSSL to provide encryption for network communications.
This can include key material used for SSL/TLS, which means that any
confidential data that has been sent over SSL/TLS may be compromised.
For full details, see the following website that describes this
vulnerability in detail:
http://heartbleed.com/
While OpenStack software itself is not directly affected, any deployment
of OpenStack is very likely using OpenSSL to provide SSL/TLS
functionality.
### Recommended Actions ###
It is recommended that you immediately update OpenSSL software on the
systems you use to run OpenStack services. In most cases, you will want
to upgrade to OpenSSL version 1.0.1g, though it is recommended that you
review the exact affected version details on the Heartbleed website
referenced above.
After upgrading your OpenSSL software, you will need to restart any
services that use the OpenSSL libraries. You can get a list of all
processes that have the old version of OpenSSL loaded by running the
following command:
lsof | grep ssl | grep DEL
Any processes shown by the above command will need to be restarted, or
you can choose to restart your entire system if desired. In an
OpenStack deployment, OpenSSL is commonly used to enable SSL/TLS
protection for OpenStack API endpoints, SSL terminators, databases,
message brokers, and Libvirt remote access. In addition to the native
OpenStack services, some commonly used software that may need to be
restarted includes:
Apache HTTPD
Libvirt
MySQL
Nginx
PostgreSQL
Pound
Qpid
RabbitMQ
Stud
It is also recommended that you treat your existing SSL/TLS keys as
compromised and generate new keys. This includes keys used to enable
SSL/TLS protection for OpenStack API endpoints, databases, message
brokers, and libvirt remote access.
In addition, any confidential data such as credentials that have been
sent over a SSL/TLS connection may have been compromised. It is
recommended that cloud administrators change any passwords, tokens, or
other credentials that may have been communicated over SSL/TLS.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0012
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Heartbleed Website: http://heartbleed.com/
CVE: CVE-2014-0160

92
security-notes/OSSN-0013 Normal file
View File

@ -0,0 +1,92 @@
Some versions of Glance do not apply property protections as expected
---
### Summary ###
Tom Leaman reported an issue to the OpenStack mailing list that
affects Glance property protections. A permissive property setting in the
Glance property protections configuration file will override any previously
set stricter ones.
### Affected Services / Software ###
Glance, Folsom, Grizzly
### Discussion ###
Glance property protections limit the users who can perform CRUD operations on
a Glance property to those in specific roles. When the property protections
rules are processed in the Folsom and Grizzly OpenStack releases, a matching
rule will only stop the processing of subsequent rules if it authorizes the
attempted action. If there is a matching rule that would reject an action that
is followed by another matching rule that would accept the action, then the
action is accepted even though one may expect it to be rejected.
In the following policy-protections.conf example, the desired result is to
restrict 'update' and 'delete' permissions for any property beginning with
'provider_' to only users with the 'admin' role.
--- begin example property-protections.conf snippet ---
[^provider_.*$]
create = admin
read = admin,_member_
update = admin
delete = admin
[.*]
create = _member_
read = _member_
update = _member_
delete = _member_
--- end example property-protections.conf snippet ---
Due to the way that the rules are processed in the Folsom and Grizzly OpenStack
releases, the admin restriction for properties beginning with 'provider_' is
nullified by the '.*' permissions since it also matches the same properties.
This results in all users with the '_member_' role being allowed the 'create',
'update', and 'delete' permissions on properties beginning with 'provider_',
which is not what was intended.
This bug only affects the use of user-roles in Glance. It does not occur when
policies are used to determine property protections.
### Recommended Actions ###
This issue has been fixed in Havana (Glance 2013.2.2) and subsequent releases
by changing the property protections rule processing to stop at the first rule
that matches the property, even if it does not allow the attempted action.
Users of affected releases should avoid using multiple rules that would match
the same property. Specifically, wildcard rules should be avoided unless they
are the most restricive rules defined.
If a permissive rule is needed that is intended to match all properties that
are not matched by other rules, a carefully crafted regular expression should
be used instead of a wildcard as demonstrated below.
--- begin example property-protections.conf snippet ---
[^provider_.*$]
create = admin
read = admin,_member_
update = admin
delete = admin
[^((?!provider_).)*$]
create = _member_
read = _member_
update = _member_
delete = _member_
--- end example property-protections.conf snippet ---
In the above example, 'create', 'update', and 'delete' operations are only
allowed for users with the '_member_' role for properties that do not begin
with 'provider_'.
Configuration files with multiple property protection entries set should be
tested to ensure that CRUD actions are constrained in the way the administrator
intended.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0013
Original Launchpad Bug : https://bugs.launchpad.net/glance/+bug/1271426
Original Report : http://lists.openstack.org/pipermail/openstack-dev/2014-January/024861.html
Glance Property Protections : https://wiki.openstack.org/wiki/Glance-property-protections
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

71
security-notes/OSSN-0014 Normal file
View File

@ -0,0 +1,71 @@
Multiple Cinder drivers set insecure file permissions
---
### Summary ###
Several Cinder volume drivers set insecure file permissions for various
files and directories. These permissions render the files accessible for
read and write to any user with access to the Cinder host as well as any
processes running on it. This exposes user block storage data to
potential disclosure, corruption, or destruction.
### Affected Services / Software ###
Cinder, Folsom, Grizzly, Havana, Icehouse
### Discussion ###
Several Cinder drivers set file permissions that allow read and write
access to 'group' and 'others'. Affected drivers include:
- GPFS
- GlusterFS
- Huawei
- NetApp/NFS
- Nexenta
- NFS
- Scality
Essentially, user volumes are made accessible to all who have access to
the Cinder host. Daemons running on the host are also able to access the
affected user volumes. The relaxed file permissions can be exploited to
disclose, modify, corrupt, or destroy user volume data.
All versions of Cinder are vulnerable in Icehouse and earlier releases
with a single exception: systems using the Icehouse GPFS driver.
This issue was reported by Dirk Mueller of SUSE.
### Recommended Actions ###
The GPFS driver in the Icehouse release fixes the file permissions issue
and also executes shell commands in non-root mode where possible.
Unfortunately, it is not practical to back-port the fix for the GPFS
driver to earlier OpenStack releases. It is anticipated that the other
affected drivers will be fixed in the OpenStack Juno release.
It is not possible to simply modify the file permissions to mitigate
the issue, as several of the affected drivers currently require the
relaxed file permissions to function. Additionally, file manipulation
cannot be uniformly restricted to a non-root user because often times a
file may be created on one host using one uid, but mounted on another
host using a different uid.
You can check what drivers are being used by Cinder by executing the
following command on your Cinder host:
> grep "^volume_driver" /etc/cinder/cinder.conf
You should compare the results of the above command against the list of
known vulerable drivers in the "Discussion" section above to see if you
are affected. If you are running the Icehouse version of Cinder and the
GPFS driver is the only driver in use, your Cinder system is not
vulnerable to this issue.
In the likely scenario that your system is vulnerable, you should limit
access to the Cinder host as much as possible. You should also explore
alternatives such as applying mandatory access control policies
(SELinux, AppArmor, etc) or using NFS uid squashing to control access
to the files in order to minimize the possible exposure.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0014
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1260679
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

46
security-notes/OSSN-0015 Normal file
View File

@ -0,0 +1,46 @@
Glance allows non-admin users to create public images
---
### Summary ###
The default policy settings in Glance allow any user to upload an image
that is publicly available to all users. This can allow a malicious user
to upload a vulnerable image that other users may use, unknowingly
exposing themselves to attack.
### Affected Services / Software ###
Glance, Folsom, Grizzly, Havana, Icehouse
### Discussion ###
When uploading an image to Glance, the user performing the upload is
able to mark the image as public. This allows all other users to see and
use the image when they create new instances. The ability to share
images with all users within an OpenStack deployment is very useful, but
it can potentially be abused for malicious purposes. For example, an
image can be uploaded that contains a backdoor that allows the attacker
to have unauthorized access to instances that are created from that
image.
Glance does allow for the ability to publicize images to be controlled
by policy. However, the default policy setting allows all users to
publicize images.
### Recommended Actions ###
It is recommended that the ability to publicize images in Glance be
restricted to trusted users, such as users with the "admin" role. This
can be done by modifying the "publicize_image" capability in Glance's
policy.json file. Here is an example of restricting this capability to
users with the "admin" role:
---- begin example policy.json snippet ----
"publicize_image": "role:admin",
---- end example policy.json snippet ----
The default policy setting in Glance is planned to be changed to
restrict the ability to publicize images to users with the "admin" role
in the Juno release of OpenStack.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0015
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1313746
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

44
security-notes/OSSN-0016 Normal file
View File

@ -0,0 +1,44 @@
Cinder wipe fails in an insecure manner on Grizzly
---
### Summary ###
A configuration error can prevent the secure erase of volumes in Cinder on
Grizzly, potentially allowing a user to recover another user’s data.
### Affected Services / Software ###
Cinder, Grizzly
### Discussion ###
In Cinder on Grizzly, a configurable method to perform a secure erase of
volumes was added. In the event of a misconfiguration no secure erase will
be performed.
The default code path in Cinder’s clear_volume() method, which is taken
in the event of a configuration error, results in no wiping of the volume -
even in the event that the user had flagged the volume for wiping.
This is the same behaviour as if the volume_clear = ‘none’ option was
selected. This could let an attacker recover data from a volume that was
intended to be securely erased. Examples of possible incorrect
configuration options include values that would appear to result in a
secure erase, for example “volume_clear = true” or “volume_clear =
yes”.
In the event of a misconfiguration resulting in this issue, the message
“Error unrecognized volume_clear option” should be present in log
files.
### Recommended Actions ###
- Create and clear a volume (cinder create --display_name erasetest 10;
cinder delete erasetest)
- Review log files for the above error message (grep “Error unrecognized
volume_clear option” <logfile>)
- Review configuration files to ensure that the valid options ‘zero’ or
‘shred’ are specified.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0016
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1322766
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

96
security-notes/OSSN-0017 Normal file
View File

@ -0,0 +1,96 @@
Session-fixation vulnerability in Horizon when using the default signed cookie sessions
---
### Summary ###
The default setting in Horizon is to use signed cookies to store
session state on the client side. This creates the possibility that if
an attacker is able to capture a user's cookie, they may perform all
actions as that user, even if the user has logged out.
### Affected Services / Software ###
Horizon, Folsom, Grizzly, Havana, Icehouse
### Discussion ###
When configured to use client side sessions, the server isn't aware
of the user's login state. The OpenStack authorization tokens are
stored in the session ID in the cookie. If an attacker can steal the
cookie, they can perform all actions as the target user, even after the
user has logged out.
There are several ways attackers can steal the cookie. One example is
by intercepting it over the wire if Horizon is not configured to use
SSL. The attacker may also access the cookie from the filesystem if
they have access to the machine. There are also other ways to steal
cookies that are beyond the scope of this note.
By enabling a server side session tracking solution such as memcache,
the session is terminated when the user logs out. This prevents an
attacker from using cookies from terminated sessions.
It should be noted that Horizon does request that Keystone invalidate
the token upon user logout, but this has not been implemented for the
Identity API v3. Token invalidation may also fail if the Keystone
service is unavailable. Therefore, to ensure that sessions are not
usable after the user logs out, it is recommended to use server side
session tracking.
### Recommended Actions ###
It is recommended that you configure Horizon to use a different session
backend rather than signed cookies. One possible alternative is to use
memcache sessions. To check if you are using signed cookies, look for
this line in Horizon's local_settings.py
--- begin example local_settings.py snippet ---
SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies'
--- end example local_settings.py snippet ---
If the SESSION_ENGINE is set to value other than
'django.contrib.sessions.backends.signed_cookies' this vulnerability
is not present. If SESSION_ENGINE is not set in local_settings.py,
check for it in settings.py.
Here are the steps to configure memcache sessions:
1. Ensure the memcached service is running on your system
2. Ensure that python-memcached is installed
3. Configure memcached cache backend in local_settings.py
--- begin example local_settings.py snippet ---
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}
--- end example local_settings.py snippet ---
Make sure to use the actual IP and port of the memcached service.
4. Add a line in local_settings.py to use the cache backend:
--- begin example local_settings.py snippet ---
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
--- end example local_settings.py snippet ---
5. Restart Horizon's webserver service (typically 'apache2' or
httpd')
Furthermore, you should always enable SSL for Horizon to help mitigate
such attack scenarios.
Please note that regardless of which session backend is used, if the
cookie is compromised, an attacker may assume all privileges of the
user for as long as their session is valid.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0017
Original LaunchPad Bug : https://bugs.launchpad.net/horizon/+bug/1327425
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Further discussion of the issue:
http://www.pabloendres.com/horizon-and-cookies/#comment-115
Django docs:
https://docs.djangoproject.com/en/1.6/ref/settings/
https://docs.djangoproject.com/en/1.6/topics/http/sessions/#configuring-sessions

63
security-notes/OSSN-0018 Normal file
View File

@ -0,0 +1,63 @@
Nova Network configuration allows guest VMs to connect to host services
---
### Summary ###
When using Nova Network to manage networking for compute instances,
instances are able to reach network services running on the host
system. This may be a security issue for the operator.
### Affected Services / Software ###
Nova, Folsom, Grizzly, Havana, Icehouse
### Discussion ###
OpenStack deployments using Nova Network, rather than Neutron for
network configuration will cause the host running the instances to be
reachable on the virtual network. Specifically, booted instances can
check the address of their gateway and try to connect to it. Any host
service which listens on the interfaces created by OpenStack and does
not apply any additional filtering will receive such traffic.
This is a security issue for deployments where the OpenStack service
users are not trusted parties, or should not be allowed to access
underlying services of the host system.
Using a specific example of devstack in default configuration, the
instance spawned inside of it will see the following routing table:
$ ip r s
default via 172.16.1.1 dev eth0
172.16.1.0/24 dev eth0 src 172.16.1.2
The instance can then use the gateway's address (172.16.1.1) to connect
to the sshd service on the host system (if one is running and listening
on all interfaces). The host system will see the connection coming from
interface `br100`.
### Recommended Actions ###
Connections like this can be stopped at various levels (libvirt filters,
specific host's iptables entries, ebtables, network service
configuration). The recommended way to protect against the incoming
connections is to stop the critical services from binding to the
Nova-controlled interfaces.
Using the sshd service as an example, the default configuration on most
systems is to bind to all interfaces and all local addresses
("ListenAddress :22" in sshd_config). In order to configure it only on
a specific interface, use "ListenAddress a.b.c.d:22" where a.b.c.d is
the address assigned to the chosen interface. Similar settings can be
found for most other services.
The list of services listening on all interfaces can be obtained by
running command 'netstat -ltu', where the '*:port' in the "Local
Address" field means the service will likely accept connections from the
local Nova instances.
If filtering of the traffic is chosen instead, care must be taken to
allow traffic coming from the running instances to services controlled
by Nova - DHCP and DNS providers.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0018
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1316271
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

62
security-notes/OSSN-0019 Normal file
View File

@ -0,0 +1,62 @@
Cinder SSH Pool will auto-accept SSH host signatures by default
---
### Summary###
In OpenStack releases prior to Juno, the SSH connection pool used by
Cinder drivers to control SAN hosts will silently auto-accept SSH host
fingerprints. This potentially allows for a man in the middle attack
through the impersonation of a legitimate storage host.
### Affected Services / Software ###
Cinder, Icehouse, Havana, Grizzly, Folsom
### Discussion ###
Cinder drivers for controlling SAN hardware communicate with storage
hosts over SSH. To facilitate creation of these drivers, Cinder provides
a utility mechanism to manage pooled SSH connections. This connection
pool is using a policy that will silently accept the SSH fingerprint
of any unknown host when it first connects. However, it is not properly
maintaing the list of known hosts and will thus permit connections to a
host regardless of the SSH fingerprint presented. This impacts all
drivers built using the utility. At the time of writing these drivers
include, but may not be limited to:
- Solaris ISCSI driver
- HP LeftHand SAN ISCSI driver
- Huawei OceanStor T series and Dorado series storage arrays
- Dell EqualLogic Storage
- IBM Storwize SVC
In the event that a malicious adversary has a point of presence on the
storage network, they could undermine network communications between
Cinder and the SAN host. Should an adversary manage to impersonate the
storage host, Cinder will silently accept the newly presented
fingerprint of the bogus host and allow the connection. This behaviour
constitutes a typical Man in the Middle attack that could intercept and
manipulate communications with the storage host, possibly leaking login
credentials.
If login credentials can be acquired, then direct interaction with the
legitimate storage host becomes possible. This could result in Cinder
volumes being accessed or modified to export compromised code and data
to other services.
The presence of this defect can be detected by initially connecting to a
storage host and then re-generating that hosts local SSH details. Cinder
will still allow connections to the host despite its now modified
fingerprint. This is the default configuration.
### Recommended Actions ###
Deployers should pay attention to the SSH interface between the Cinder
driver and the SAN host and take appropriate measures to defend the
storage network. These measures could include physical network isolation
or placing an Intrusion Detection System on the network. The IDS should
detect attacks such as ARP table poisoning, DHCP spoofing or DNS forgery
that could be used to impersonate a SAN host and enact an Man in the
Middle attack.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0019
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1320056
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

69
security-notes/OSSN-0021 Normal file
View File

@ -0,0 +1,69 @@
Owners of compromised accounts should verify Keystone trusts
---
### Summary ###
The Keystone 'trusts' API allows for delegation of privileges to one
user on behalf of another. This API can allow for an attacker of a
compromised account to set up backdoor access into the account. This
backdoor may not be easily detected, even if the account compromise is
detected.
### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse
### Discussion ###
The Keystone trusts system allows for delegation of roles to Keystone
users without disclosing the main token, or sharing the account secret
key with those users. That means, after an account is compromised, the
change of the secret key and the invalidation of existing tokens may not
be enough to prevent future access from an attackers.
If an attacker obtains access to the account (via stolen credentials or
service exploitation), they can create a new Keystone trust. This new
trust may grant access not dependent on any knowledge of the compromised
user's secret key and can also be set to never expire. In this case, the
trust has to be manually found and removed by the account owner.
Information about using trusts can be found at:
https://wiki.openstack.org/wiki/Keystone/Trusts
### Recommended Actions ###
If the account has been compromised, or is being audited, the owner
should check the list of active trusts and verify that:
- all the active trusts are needed
- all the active trusts have the expected roles and delegation depth
- all the active trusts have appropriate expiration lifetimes
At the time of writing this OSSN, trusts can be listed by using the
Keystone API directly:
---- begin CLI example ----
# get ENDPOINT from the last field of the output
keystone endpoint-get --service identity --attr versionId \
--value 3.0
# get TOKEN from the last field of the output
keystone token-get
# list the trusts by running:
curl -i -X GET "ENDPOINT/trusts/" -H "X-Auth-Token: TOKEN" \
-H "Content-Type: application/json" -H "Accept: application/json"
---- end CLI example ----
If some trust (with id TRUST_ID) is identified as invalid, it can be
deleted using:
---- begin CLI example ----
curl -i -X DELETE "ENDPOINT/trusts/TRUST_ID" \
-H "X-Auth-Token: TOKEN" -H "Content-Type: application/json" \
-H "Accept: application/json"
---- end CLI example ----
In the future, operators will be able to use keystoneclient for a more
convenient method of accessing and updating this information.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0021
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1341849
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

57
security-notes/OSSN-0022 Normal file
View File

@ -0,0 +1,57 @@
Nova Networking does not enforce security group rules following a soft
reboot of an instance
---
### Summary ###
In deployments using Nova Networking, security group rules associated
with an instance may not be enforced after a soft reboot. Nova is
designed to apply the configured security group rules to an instance
when certain operations are performed, such as a normal boot operation.
If an operation has been performed that results in the clearing of
security group rules, such as restarting the nova compute service, then
performing a soft reboot of that instance will cause it to be
started without security group rules being applied.
Deployments using Neutron are not impacted.
### Affected Services / Software ###
Nova, Havana, Grizzly
### Discussion ###
In Nova deployments using Nova Networking, security groups are
implemented using iptables, which is used to configure and control
network traffic into Nova instances. When an instance is first booted
using the normal boot method (nova boot <instance_id>), the security
group rules are applied to that instance.
When an instance is rebooted using the soft reboot method (nova reboot
<instance_id>), the security group rules are not reapplied since they
should have been already applied when the instance was initially
booted. If the security group rules have not been applied following an
event that resulted in their clearing, such as restarting the compute
service, the instance will be brought up without security group
enforcement. This situation is most likely to arise in cases where the
Nova compute service has been terminated or restarted, which removes
all iptables rules. If a stopped instance is then started by using a
soft reboot, it will not have any security group rules applied. A hard
reboot (nova reboot --hard <instance_id>) reapplies the security group
rules, so it is not susceptible to this issue.
Depending on the deployment architecture, this could breach security
assumptions and leave an instance vulnerable to network based attacks.
This issue only affects the Havana and Grizzly releases. The Icehouse
release does not allow a stopped instance to be started using a soft
reboot, therefore this issue does not affect the Icehouse release.
### Recommended Actions ###
Do not to use the soft reboot method to start instances from the
stopped state. If instances are in the stopped state, boot using "nova
boot <instance_id>" or reboot using "nova reboot --hard <instance_id>"
to force the security group rules to be applied.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0022
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1316822
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

28
security-notes/README.md Normal file
View File

@ -0,0 +1,28 @@
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

26
security-notes/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 OSSN on wiki>
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>