OpenStack - User contributions [en]

OSSN/OSSN-0084

2018-07-10T08:17:43Z

Lhinds:

__NOTOC__

== Data retained after deletion of a ScaleIO volume ==

=== Summary ===
Certain storage volume configurations allow newly created volumes to
contain previous data. This could lead to leakage of sensitive
information between tenants.

=== Affected Services / Software ===
Cinder releases up to and including Queens with ScaleIO volumes
using thin volumes and zero padding.

=== Discussion ===
Using both thin volumes and zero padding does not ensure data contained
in a volume is actually deleted. The default volume provisioning rule is
set to thick so most installations are likely not affected. Operators
can check their configuration in `cinder.conf` or check for zero padding
with this command `scli --query_all`.

=== Recommended Actions ===

Operators can use the following two workarounds, until the release of
Rocky (planned 30th August 2018) which resolves the issue.

1. Swap to thin volumes

2. Ensure ScaleIO storage pools use zero-padding with:

scli --modify_zero_padding_policy
(((--protection_domain_id <ID> |
--protection_domain_name <NAME>)
--storage_pool_name <NAME>) | --storage_pool_id <ID>)
(--enable_zero_padding | --disable_zero_padding)`

=== Contacts / References ===
Author: Nick Tait

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573

Mailing List : [Security] tag on openstack-dev@lists.openstack.org

OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0084

2018-07-10T08:17:27Z

Lhinds:

__NOTOC__

== Data retained after deletion of a ScaleIO volume ==

=== Summary ===
Certain storage volume configurations allow newly created volumes to
contain previous data. This could lead to leakage of sensitive
information between tenants.

=== Affected Services / Software ===
Cinder releases up to and including Queens with ScaleIO volumes
using thin volumes and zero padding.

=== Discussion ===
Using both thin volumes and zero padding does not ensure data contained
in a volume is actually deleted. The default volume provisioning rule is
set to thick so most installations are likely not affected. Operators
can check their configuration in `cinder.conf` or check for zero padding
with this command `scli --query_all`.

=== Recommended Actions ===

Operators can use the following two workarounds, until the release of
Rocky (planned 30th August 2018) which resolves the issue.

1. Swap to thin volumes

2. Ensure ScaleIO storage pools use zero-padding with:

`scli --modify_zero_padding_policy
(((--protection_domain_id <ID> |
--protection_domain_name <NAME>)
--storage_pool_name <NAME>) | --storage_pool_id <ID>)
(--enable_zero_padding | --disable_zero_padding)`

=== Contacts / References ===
Author: Nick Tait

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573

Mailing List : [Security] tag on openstack-dev@lists.openstack.org

OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0084

2018-06-08T10:17:16Z

Lhinds:

__NOTOC__

== Data retained after deletion of a ScaleIO volume ==

=== Summary ===
Certain storage volume configurations allow newly created volumes to
contain previous data. This could lead to leakage of sensitive
information between tenants.

=== Affected Services / Software ===
Cinder releases up to and including Queens with ScaleIO volumes
using thin volumes and zero padding.

=== Discussion ===
Using both thin volumes and zero padding does not ensure data contained
in a volume is actually deleted. The default volume provisioning rule is
set to thick so most installations are likely not affected. Operators
can check their configuration in `cinder.conf` or check for zero padding
with this command `scli --query_all`.

=== Recommended Actions ===

Update Cinder to Rocky or later.

Alternatively operators can use one of two workarounds:

Swap to thin volumes

Ensure ScaleIO storage pools use zero-padding with:
`scli --modify_zero_padding_policy
(((--protection_domain_id <ID> |
--protection_domain_name <NAME>)
--storage_pool_name <NAME>) | --storage_pool_id <ID>)
(--enable_zero_padding | --disable_zero_padding)`

=== Contacts / References ===
Author: Nick Tait

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573

Mailing List : [Security] tag on openstack-dev@lists.openstack.org

OpenStack Security Project : https://launchpad.net/~openstack-ossg

Security/Projects/Bandit

2018-05-03T11:44:02Z

Lhinds: update about project moving to PyCQA

==Project Moved==

Please note that Bandit is no longer maintained under OpenStack and has been moved to the Python Code Quality Authority:

https://github.com/PyCQA/bandit

All patches and issues should be raised on the PyCQA github repository.

==Overview==
Bandit is a security linter for Python source code, utilizing the [https://docs.python.org/2/library/ast.html ast] module from the Python standard library.

The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. As it matures and is proven to be useful, we see it being a possible addition to OpenStack CI gate tests with non-voting and eventually voting capabilities.

Bandit can be obtained by cloning the repository at <nowiki>https://git.openstack.org/openstack/bandit.git</nowiki>. The [http://git.openstack.org/cgit/openstack/bandit/tree/README.rst README.rst] file contains documentation regarding installation, usage, and configuration.

There is [https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/securing-the-openstack-code-base-with-bandit a video of bandit being presented at the OpenStack 2015 Summit in Vancouver].

==Contributing==
Bandit makes use of the OpenStack CI infrastructure provided through OpenStack:
* Read-only OpenStack git repository: [https://github.com/openstack/bandit https://github.com/openstack/bandit]
* Browsable OpenStack git repository: [https://git.openstack.org/cgit/openstack/bandit/ https://git.openstack.org/cgit/openstack/bandit/]
* Launchpad bug reporting and tracking: https://launchpad.net/bandit
* Gerrit endpoint for git repository: ssh://[username]@review.openstack.org:29418/openstack/bandit.git
* Gerrit reviews: [https://review.openstack.org/#/q/project:openstack/bandit,n,z https://review.openstack.org/#/q/project:openstack/bandit,n,z]

An easy way to contribute is to write a plugin/test that will allow Bandit to identify more security issues. Extensions and improvements to the underlying framework are also welcomed, although we'll be attempting to maintain stability in the interface that is presented to plugins.

See [http://docs.openstack.org/infra/manual/developers.html#development-workflow Development Workflow] for information on the general contribution/review workflow.

==Gate Testing with Bandit==
Bandit can help maintain the security of OpenStack projects when it's used as a gate test. Projects such as [http://docs.openstack.org/developer/keystone/ Keystone] have created a gate test which runs Bandit to ensure that common security code mistakes are not introduced when code is modified. New: you now have two ways to set up a Bandit gate and we'll cover the steps for both below.

===Full run Bandit gate:===
This option works well for projects that already have clean Bandit runs. To set up a full run Bandit gate for an OpenStack project, follow these steps:

# Add '''bandit''' (the package name on pypi) to the '''test-requirements.txt''' file. See [http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt global-requirements.txt] and copy the bandit line. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot.
# We need to have bandit in 2 tox environments: A '''bandit''' env that's used by the bandit team for integration tests, and the '''pep8''' env. See [http://git.openstack.org/cgit/openstack/keystone/tree/tox.ini Keystone's] for an example.

The following is a good starting point:

# B105-B107: hardcoded password checks - likely to generate false positives in a gate environment
# B401: import subprocess - not necessarily a security issue; this plugin is mainly used for penetration testing workflow
# B603,B606: process without shell - not necessarily a security issue; this plugin is mainly used for penetration testing workflow
# B607: start process with a partial path - this should be a project level decision
bandit -r ''project'' -x tests -s B105,B106,B107,B404,B603,B606,B607

Test this by running '''tox -e pep8'''. Initially, there will likely be several other tests that fail. Exclude these and work on fixing them in separate commits.

If you have any questions or comments please contact tmcpeak or tkelsey in #openstack-security on Freenode IRC.

===Bandit Baseline Gate===
This is the best option for projects which may have some legacy Bandit findings. Just because a project has some pre-existing security issues doesn't mean Bandit can't help prevent new ones! To set up a Bandit Baseline gate for an OpenStack project, follow these steps:

# Decide on the appropriate tests to run, not every test supported by bandit will be a good fit for every project. The bandit command line arguments -s and -t can be used to filter the test set to run.
# (optional) Add a Bandit config for your project. If you need to configure specific test parameters, in addition to switching tests on or off wholesale, then a bandit config may be needed. Bandit ships with the tool 'bandit-config-generator' that can help generate a config file if needed. This config is completely optional and is only needed if the defaults for specific tests are not sufficient.
# Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot.
# Add a tox environment to run the Bandit basline. To do this we'll add two targets:
##a standalone target "codesec" [https://github.com/openstack/bandit/blob/master/tox.ini#L31-L35 codesec tox target] which is useful for developers to check their changes
##a "linters" target: [https://github.com/openstack/bandit/blob/master/tox.ini#L18-L23 linters tox target]. By adding a linters target, we're extending our linters to run Bandit in addition to the normal flake8 tests.
## In both cases the arguments for 'bandit-baseline' should be identical to what you want to pass into Bandit. For example, if you created a config file above, you'll want to specify it with '-c myconfig.yaml'. In the example above we're running: 'bandit-baseline -r bandit -ll -ii' which tells Bandit (and bandit-baseline) to run scan the 'bandit' directory recursively and filter medium+ severity and confidence issues.
# Change the OpenStack infra zuul/layout.yaml for your project to use 'python-jobs-linters' instead of 'python-jobs' like we did for the Bandit project itself here: [https://review.openstack.org/#/c/260135/5/zuul/layout.yaml zuul layout change example]. This enables your project to use the 'linters' target in your python-jobs gate instead of just flake8. Note: if you do this you'll have a voting Bandit gate. You should make sure you're comfortable with Bandit and how it works before changing this.

==Per-task Configurations==
By default Bandit runs all plugins that it finds in the plugins directory. While this may be useful for doing a thorough manual review, for use cases such as automation and gate testing, this is probably overkill. When it is desirable to create specific sets of tests for specific tasks you should create a config file file for each task. This file can control the list of tests that should be run as well as tuning any parameters relevant to those tests. Once a custom config has been created, you can run it by using the "-c" command line option to point to the config file. Another way to control the tests that are run is to use the -t and -s command line options to select a set of tests, this is normally more convenient than using a full blown config when test parameters don't need refining.

==TODO==
TODO is now tracked using blueprints in Launchpad: https://blueprints.launchpad.net/bandit

==Projects using bandit==
{| class="wikitable sortable"
|-
! Project name !! Status
|-
| anchor ||
experimental
|-
| cinder ||
non-voting
|-
| designate ||
non-voting
|-
| keystone ||
voting
|-
| keystonemiddleware ||
voting
|-
| octavia ||
voting
|-
| python-keystoneclient ||
voting
|-
| swauth ||
voting
|}

==Team==
Bandit is a tool from the [https://security.openstack.org OpenStack Security] project.

Core project team:
* Jamie Finnigan (chair6)
* Travis McPeak (tmcpeak)
* Tim Kelsey (tkelsey)
* Eric Brown (browne)
* Ian Cordasco (sigmavirus24)
* Stan Pitucha (viraptor)
* Luke Hinds (lhinds)
* Gage Hugo (gagehugo)

Security-SIG

2018-04-26T09:07:27Z

Lhinds:

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security SIG. The Security SIG is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security Project. The Security SIG undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

== Organization and Contribution ==
The Security SIG is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack clouds! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, cross project collaboration, writing documentation or inventing cool new features and tooling - we want to hear from you!

== Organization and Contribution ==

=== Leadership ===

The security SIG has no formal leadership, instead it has chairs who arrange meetings and organise votes.. The current chairs are Luke Hinds (Red Hat) and Gage Hugo (AT&T).

Chair duty rotates each month.

==== IRC ====
The security SIG has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security SIG meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security SIG has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security SIG].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

=== Tatu - SSH certificate and bastion management ===

[[Tatu]] is an OpenStack service that manages SSH user and host certificates. Tatu can also start and manage bastion servers so that you don't have to (and you don't have to give every SSH server a public IPv4 address).

* [https://git.openstack.org/cgit/openstack/tatu Tatu Git Repository]
* [https://review.openstack.org/#/q/tatu,n,z Tatu Gerrit]
* [https://bugs.launchpad.net/tatu Tatu Launchpad]

== Advisory Activities ==
The Security SIG issues Security Notes targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it. The Security SIG works closely with the VMT assisting with feedback on various issues.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security SIG write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security SIG in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

OSSN/OSSN-0083

2018-04-24T13:08:50Z

Lhinds:

__NOTOC__

== Keystone policy rule "identity:get_identity_providers" was ignored ==

Keystone policy rule "identity:get_identity_providers" was ignored
---

=== Summary ===
A policy rule in Keystone did not behave as intended leading to a less
secure configuration than would be expected.

=== Affected Services / Software ===
OpenStack Identity Service (Keystone) versions through Mitaka, as well
as Newton (<= 10.0.3), and Ocata (<= 11.0.3).

=== Discussion ===
Deployments were unaffected by this problem if the default rule was
changed or the "get_identity_providers" rule was manually changed to
be "get_identity_provider" (singular) in keystone's `policy.json`.

A spelling mistake in the default policy configuration caused these
rules to be ignored. As a result operators that attempted to restrict
this API were unlikely to actually enforce it.

=== Recommended Actions ===
Update Keystone to a minimum version of 12.0.0.0b3. Additionally, this
fix has been backported to Ocata (11.0.3) and Newton (10.0.3).

Fix any lingering rules: `identity:get_identity_providers` should
be changed to `identity:get_identity_provider`.

=== Contacts / References ===
Author: Nick Tait

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0083

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1703369

Mailing List : [Security] tag on openstack-dev@lists.openstack.org

OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0083

2018-04-24T13:08:30Z

Lhinds:

OSSN/OSSN-0083

2018-04-24T13:08:15Z

Lhinds:

__NOTOC__

== Keystone policy rule "identity:get_identity_providers" was ignored ==

Keystone policy rule "identity:get_identity_providers" was ignored
---

=== Summary ===
A policy rule in Keystone did not behave as intended leading to a less
secure configuration than would be expected.

=== Affected Services / Software ===
OpenStack Identity Service (Keystone) versions through Mitaka, as well
as Newton (<= 10.0.3), and Ocata (<= 11.0.3).

=== Discussion ===
Deployments were unaffected by this problem if the default rule was
changed or the "get_identity_providers" rule was manually changed to
be "get_identity_provider" (singular) in keystone's `policy.json`.

A spelling mistake in the default policy configuration caused these
rules to be ignored. As a result operators that attempted to restrict
this API were unlikely to actually enforce it.

=== Recommended Actions ===
Update Keystone to a minimum version of 12.0.0.0b3. Additionally, this
fix has been backported to Ocata (11.0.3) and Newton (10.0.3).

Fix any lingering rules: `identity:get_identity_providers` should
be changed to `identity:get_identity_provider`.

=== Contacts / References ===
Author: Nick Tait
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0083
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1703369
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg

https://bugs.launchpad.net/ossn/+bug/1703369

Security SIG

2018-04-05T14:33:47Z

Lhinds:

Please go here: https://wiki.openstack.org/wiki/Security-SIG

Security SIG

2018-04-05T14:33:16Z

Lhinds: Blanked the page

Security-SIG

2018-04-05T14:32:23Z

Lhinds: /* Leadership */

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security SIG. The Security SIG is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security Project. The Security SIG undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

== Organization and Contribution ==
The Security SIG is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack clouds! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, cross project collaboration, writing documentation or inventing cool new features and tooling - we want to hear from you!

== Organization and Contribution ==

=== Leadership ===

The security SIG has no formal leadership, instead it has chairs who arrange meetings and organise votes.. The current chairs are Luke Hinds (Red Hat) and Gage Hugo (AT&T).

==== IRC ====
The security SIG has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security SIG meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security SIG has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security SIG].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

=== Tatu - SSH certificate and bastion management ===

[[Tatu]] is an OpenStack service that manages SSH user and host certificates. Tatu can also start and manage bastion servers so that you don't have to (and you don't have to give every SSH server a public IPv4 address).

* [https://git.openstack.org/cgit/openstack/tatu Tatu Git Repository]
* [https://review.openstack.org/#/q/tatu,n,z Tatu Gerrit]
* [https://bugs.launchpad.net/tatu Tatu Launchpad]

== Advisory Activities ==
The Security SIG issues Security Notes targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it. The Security SIG works closely with the VMT assisting with feedback on various issues.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security SIG write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security SIG in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

Security-SIG

2018-04-05T14:32:02Z

Lhinds:

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security SIG. The Security SIG is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security Project. The Security SIG undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

== Organization and Contribution ==
The Security SIG is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack clouds! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, cross project collaboration, writing documentation or inventing cool new features and tooling - we want to hear from you!

== Organization and Contribution ==

== Leadership ==

The security SIG has no formal leadership, instead it has chairs who arrange meetings and organise votes.. The current chairs are Luke Hinds (Red Hat) and Gage Hugo (AT&T).

==== IRC ====
The security SIG has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security SIG meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security SIG has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security SIG].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

=== Tatu - SSH certificate and bastion management ===

[[Tatu]] is an OpenStack service that manages SSH user and host certificates. Tatu can also start and manage bastion servers so that you don't have to (and you don't have to give every SSH server a public IPv4 address).

* [https://git.openstack.org/cgit/openstack/tatu Tatu Git Repository]
* [https://review.openstack.org/#/q/tatu,n,z Tatu Gerrit]
* [https://bugs.launchpad.net/tatu Tatu Launchpad]

== Advisory Activities ==
The Security SIG issues Security Notes targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it. The Security SIG works closely with the VMT assisting with feedback on various issues.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security SIG write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security SIG in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

Security/Threat Analysis

2018-03-14T13:54:41Z

Lhinds:

== OpenStack Threat Modelling ==
Security is one of the biggest concern for any cloud solutions. The aim of this project is proactively identify threats and weakness in OpenStack Cloud and contribute to build a secure and robust platform. Threat modelling takes a comprehensive look at the system at hand – components, protocols and code - against the existence and capability of an adversary looking for known vulnerabilities. When a threat is identified, it is tallied and reported to the development team. In some cases, the threat analysis team may also include a suggestion to fix the vulnerabilities and related threat. A simplified view of threat modelling steps are provided below:

<gallery widths=550px heights=400px>
File:Threat_Modeling_steps.png
</gallery>

==== Threat Modelling Process for OpenStack Projects ====
Check the [[Security/Threat_Analysis/process|process page]] to know the overall process

Technical steps are defined below:
[https://github.com/shohel02/OpenStack_Threat_Modelling/blob/master/Threat_modeling_process.md Threat Modelling process]

===== Git Repo: =====

https://git.openstack.org/openstack/security-analysis

=== Archive ===

Earlier we have used Google Docs for sharing documents, documents are still shared from Google Docs,
but we are focusing to use GIT as a repository containing all docs.

[https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing Keystone Threat Modelling]

https://github.com/shohel02/OpenStack_Threat_Modelling

===== Nova: =====

Includes a High Level Threat Model Analysis for Nova.
This is WIP, documentation is still in DRAFT version.

https://github.com/criscad/OpenStack_Threat_Modelling.git

=== Earlier reports on Threat Modelling related to OpenStack ===
#Threat Analysis Example
[[File:Threat analysis Example.pdf|thumbnail|Threat Analysis Example]]
# Keystone GAP and Threat Identification for Folsom Release (Quick Study)
[[File:OpenStack Keystone Analysis.pdf|OpenStack Keystone GAP and Threat Identification]]

=== Existing Literature Study ===
==== Process ====
# [https://www.owasp.org/index.php/Threat_Risk_Modeling%20 https://www.owasp.org/index.php/Threat_Risk_Modeling ]
# Michael Howard, David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press
# Ross Anderson, Security Engineering, Chapter 11 http://www.cl.cam.ac.uk/~rja14/book.html

==== Existing Threat Analysis Work related to Cloud ====
# The Notorious Nine, Cloud Security Alliance [https://downloads.cloudsecurityalliance.org/initiatives/top_threats/The_Notorious_Nine_Cloud_Computing_Top_Threats_in_2013.pdf The_Notorious_Nine_Cloud_Computing_Top_Threats_in_2013.pdf]

==== Identity and Access Management System Analysis ====
# Identity Management Protection Profile, http://www.commoncriteriaportal.org/files/ppfiles/pp0024b.pdf

Meetings/OpenStackSecurity

2018-03-06T11:50:54Z

Lhinds:

= [[OpenStack]] Security SIG Meetings =
The security team holds public meetings in #openstack-meeting-alt. Everyone is encouraged to attend.
* Thursdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0 15:00 UTC]

Please also use the mailing list for ongoing discussions (openstack-dev@lists.openstack.org) using the [Security] tag

== Agenda for next meeting ==
* Roll Call
* Reminder that the agenda exists
* Anchor Update
* Bandit Update
* OpenStack Security Guide Update
* OpenStack Security Notes Update
* Security Mid-Cycle Meetup
* Open Bugs Requiring Review
* Crypto Oversight
* API Testing
* Formalizing the meeting process
* AOB

== Transcripts from Previous Meetings ==

The full index of all previous meeting transcripts is available at http://eavesdrop.openstack.org/meetings/openstack_security_group/.

==== 2016 ====
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-04-14-17.00.html 14 April 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-04-07-17.00.html 07 April 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31-17.00.html 31 March 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-24-17.00.html 24 March 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-17-17.00.html 17 March 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-03-17.00.html 03 March 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-02-25-17.01.html 25 February 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-02-18-17.00.html 18 February 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-02-11-17.00.html 11 February 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-02-04-17.00.html 04 February 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-01-28-17.01.html 28 January 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-01-21-17.02.html 21 January 2016]
* [http://eavesdrop.openstack.org/meetings/security/2016/security.2016-01-07-17.00.html 07 January 2016]

==== 2015 ====
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-07-09-17.00.html 09 July 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-07-02-17.00.html 02 July 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-06-25-17.00.html 25 June 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-06-18-17.01.html 18 June 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-06-11-17.02.html 11 June 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-06-04-17.01.html 06 June 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-05-28-17.00.html 28 May 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-05-07-17.00.html 07 May 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-04-30-17.00.html 30 April 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-04-23-17.02.html 23 April 2015]
* [http://eavesdrop.openstack.org/meetings/security/2015/security.2015-04-16-17.01.html 16 April 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-04-02-17.00.html 02 April 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-03-26-17.00.html 26 March 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-03-19-17.01.html 19 March 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-03-12-17.03.html 12 March 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-03-05-17.02.html 05 March 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-02-26-17.00.html 26 February 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-02-19-17.00.html 19 February 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-02-12-17.04.html 12 February 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-01-29-17.00.html 29 January 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-01-22-17.03.html 22 January 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-01-15-17.00.html 15 January 2015]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2015/openstack_security_group.2015-01-08-17.01.html 08 January 2015]

==== 2014 ====
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-12-18-17.00.html 18 December 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-12-11-17.00.html 11 December 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-12-04-17.00.html 04 December 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-11-27-17.07.html 27 November 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-11-20-17.03.html 20 November 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-11-13-17.01.html 13 November 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-10-30-17.04.html 30 October 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-10-23-17.00.html 23 October 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-10-16-17.04.html 16 October 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-10-09-17.02.html 09 October 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-10-02-17.00.html 02 October 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-09-25-17.00.html 25 September 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-09-18-17.00.html 18 September 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-09-11-17.05.html 11 September 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-08-28-17.02.html 28 August 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-08-14-17.00.html 14 August 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-08-07-17.00.html 08 August 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-07-31-17.01.html 31 July 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-07-24-17.01.html 24 July 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-07-10-17.02.html 10 July 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-07-03-17.01.html 03 July 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-06-26-17.02.html 26 June 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-06-19-17.01.html 19 June 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-06-12-17.02.html 12 June 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-06-05-18.00.html 5 June 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-05-29-18.00.html 29 May 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-05-22-18.01.html 22 May 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-05-01-18.03.html 1 May 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-04-24-18.00.html 24 April 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-04-17-18.01.html 17 April 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-04-10-18.00.html 10 April 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-04-03-18.00.html 03 April 2014, part 2]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-04-03-17.02.html 03 April 2014, part 1]
* 27 Mar 2014 -- No meeting
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-03-20-18.01.html 20 March 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-03-13-18.00.html 13 March 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-03-06-18.00.html 6 March 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-02-27-18.00.html 27 Feb 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-02-20-18.00.html 20 Feb 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-02-13-18.00.html 13 Feb 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-02-06-18.00.html 6 Feb 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-01-30-18.00.html 30 Jan 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-01-23-18.00.html 23 Jan 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-01-16-18.00.html 16 Jan 2014]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-01-09-18.02.html 9 Jan 2014]

==== 2013 ====
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-12-19-18.00.html 19 Dec 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-12-12-18.01.html 12 Dec 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-12-05-18.00.html 5 Dec 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-11-21-18.00.html 21 Nov 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-11-14-18.06.html 14 Nov 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-10-24-18.07.html 24 Oct 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-10-17-18.01.html 17 Oct 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-10-10-18.01.html 10 Oct 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-10-03-18.00.html 3 Oct 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-09-26-18.05.html 26 Sept 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-09-19-18.00.html 19 Sept 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-09-12-18.01.html 12 Sept 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-08-29-18.03.html 29 August 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-08-22-18.00.html 22 August 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-08-15-18.03.html 15 August 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-08-08-18.00.html 8 August 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-08-01-18.06.html 1 August 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-07-25-18.02.html 25 July 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-07-18-18.00.html 18 July 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-07-11-18.00.html 11 July 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-06-20-18.04.html 20 June 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-06-13-18.00.html 13 June 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-06-06-18.01.html 6 June 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-05-30-18.03.html 30 May 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-05-23-18.00.html 23 May 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-05-16-18.00.html 16 May 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-05-09-18.00.html 9 May 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-05-02-18.01.html 2 May 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-04-25-18.10.html 25 Apr 2013] (see also [[OSSG_25April2013_Minutes]])
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-04-04-18.00.html 4 Apr 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-03-28-18.00.html 28 Mar 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-03-21-18.07.html 21 Mar 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-03-14-18.01.html 14 Mar 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-03-07-18.00.html 7 Mar 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-02-28-18.00.html 28 Feb 2013]
* [http://eavesdrop.openstack.org/meetings/ossg/2013/ossg.2013-02-21-18.01.html 21 Feb 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-02-14-18.04.html 14 Feb 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-02-07-18.08.html 7 Feb 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-01-31-18.00.html 31 Jan 2013]
* [http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-01-24-18.00.html 24 Jan 2013]

Security/How To Contribute

2018-03-06T11:50:00Z

Lhinds:

== How to contribute to the OpenStack Security SIG ==

=== Initial Steps for Everyone ===
# Join the SIG launchpad group: https://launchpad.net/~openstack-ossg
# Join the OpenStack Security SIG mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
# Introduce yourself at the weekly Security SIG meeting on IRC: https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity
# Read the sections below for specific ways that someone with your skills can help improve the security of OpenStack.

=== Developers, New to OpenStack ===
* Set yourself up to contribute to OpenStack (see the “If you’re a developer” section): https://wiki.openstack.org/wiki/How_To_Contribute
* Review code reviews tagged as SecurityImpact
:* Notifications come to the openstack-security mailing list
:* https://review.openstack.org/#/q/message:SecurityImpact+is:open,n,z
* Identify open bugs that you can work on to learn a project (we recommend starting with just one project before branching out too much)
:* Compute (Nova): https://bugs.launchpad.net/nova
:* Object Storage (Swift): https://bugs.launchpad.net/swift/
:* Image Service (Glance): https://bugs.launchpad.net/glance
:* Identity (Keystone): https://bugs.launchpad.net/keystone
:* Dashboard (Horizon): https://bugs.launchpad.net/horizon
:* Networking (Neutron): https://bugs.launchpad.net/neutron
:* Block Storage (Cinder): https://bugs.launchpad.net/cinder
:* Common Code (Oslo): https://bugs.launchpad.net/oslo
* Review code to learn a project and find security issues (we recommend starting with just one project before branching out too much)
:* Compute (Nova): https://github.com/openstack/nova
:* Object Storage (Swift): https://github.com/openstack/swift
:* Image Service (Glance): https://github.com/openstack/glance
:* Identity (Keystone): https://github.com/openstack/keystone
:* Dashboard (Horizon): https://github.com/openstack/horizon
:* Networking (Neutron): https://github.com/openstack/neutron
:* Block Storage (Cinder): https://github.com/openstack/cinder
:* Common Code (Oslo): https://github.com/openstack/oslo-incubator

=== Developers, Experienced with OpenStack ===
* Security leadership on specific OpenStack project
:* SIG people with both a strong security background and a strong OpenStack background to work as core developers on projects. These people would help serve as the link between OSSG and the OpenStack project by:
::* Identifying areas where the code should be improved
::* Writing blueprints for security features related to that project
::* Ensuring relevant reviews are marked with SecurityImpact tags
::* Leveraging OSSG members to help solve security problems
::* Become a trusted security resource among the core developers
:* This is a position that one grows into by demonstrating good work over time. This is not something where you are simply appointed. If you are interested, OSSG can help get you started.
* Identify security-relevant code reviews and tag as SecurityImpact
* Review code reviews tagged as SecurityImpact
:* Notifications come to the openstack-security mailing list
:* https://review.openstack.org/#/q/message:SecurityImpact+is:open,n,z
* Review blueprints
:* Compute (Nova): https://blueprints.launchpad.net/nova
:* Object Storage (Swift): https://blueprints.launchpad.net/swift
:* Image Service (Glance): https://blueprints.launchpad.net/glance
:* Identity (Keystone): https://blueprints.launchpad.net/keystone
:* Dashboard (Horizon): https://blueprints.launchpad.net/horizon
:* Networking (Neutron): https://blueprints.launchpad.net/neutron
:* Block Storage (Cinder): https://blueprints.launchpad.net/cinder
:* Common Code (Oslo): https://blueprints.launchpad.net/oslo
* Write security-relevant blueprints

=== Security Architects ===
* Review / edit / add to the OpenStack Security Guide
:* Webpage: http://docs.openstack.org/sec/
:* DocBook Source: https://github.com/openstack/security-doc/tree/master/security-guide
* Review / edit / create OSSNs
:* https://wiki.openstack.org/wiki/Security/Security_Note_Process
:* https://launchpad.net/ossn
* Review blueprints (see links in developer section above)
* Write security-relevant blueprints

=== Writers / Editors ===
* Initial setup instructions can be found at the Documentation First Timer's How To page: https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers
* Once those steps are complete, you can help review / edit the OpenStack Security Guide
:* Webpage: http://docs.openstack.org/sec/
:* DocBook Source: https://github.com/openstack/security-doc/tree/master/security-guide
:* List of Enhancements / Bugs: https://bugs.launchpad.net/openstack/+bugs?field.tag=sec-guide
:* Open a new Enhancement / Bug: File a bug on https://bugs.launchpad.net/openstack-manuals/+filebug and tag it with "sec-guide". Option for tags is available under "Extra options".

* Review / edit OSSNs
:* https://wiki.openstack.org/wiki/Security/Security_Note_Process
:* https://launchpad.net/ossn

=== QA / Automation / Software Development Engineer in Test (SDET) ===
* Add security testing to current test suites
* Add security tests to OS projects
* Learn to identify and file Security Bugs
* Identify open bugs and/or report security bugs that you can work on to learn a project (we recommend starting with just one project before branching out too much)
:* Compute (Nova): https://bugs.launchpad.net/nova
:* Object Storage (Swift): https://bugs.launchpad.net/swift/
:* Image Service (Glance): https://bugs.launchpad.net/glance
:* Identity (Keystone): https://bugs.launchpad.net/keystone
:* Dashboard (Horizon): https://bugs.launchpad.net/horizon
:* Networking (Neutron): https://bugs.launchpad.net/neutron
:* Block Storage (Cinder): https://bugs.launchpad.net/cinder
:* Common Code (Oslo): https://bugs.launchpad.net/oslo

=== Other Tasks ===
* Create / update common OSSG presentation slides

Security-SIG

2018-02-26T10:47:19Z

Lhinds:

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security SIG. The Security SIG is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security Project. The Security SIG undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

== Organization and Contribution ==
The Security SIG is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack clouds! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, cross project collaboration, writing documentation or inventing cool new features and tooling - we want to hear from you!

==== IRC ====
The security SIG has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security SIG meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security SIG has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Anchor - Ephemeral PKI ===
Anchor is a lightweight, open source, Public Key Infrastructure (PKI), which uses automated provisioning of short-term certificates to enable cryptographic trust in OpenStack services. Certificates are typically valid for 12-24 hours and are issued based on the result from a policy enforcing decision engine. Short term certificates enable passive revocation, to bypass the issues with the traditional revocation mechanisms used in most PKI deployments.

* [https://git.openstack.org/cgit/openstack/anchor Anchor Git Repository]
* [https://review.openstack.org/#/q/anchor,n,z Anchor Gerrit]
* [https://bugs.launchpad.net/anchor Anchor Launchpad]
* [https://www.youtube.com/watch?v=jf_YOzW7I3s Summit Announcement Video]
* [https://www.youtube.com/watch?v=Q_ZhrQq-_YM Summit Followup Video]

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security SIG].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

== Advisory Activities ==
The Security SIG issues Security Notes targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it. The Security SIG works closely with the VMT assisting with feedback on various issues.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security SIG write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security SIG in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

Security-SIG

2018-02-26T10:45:42Z

Lhinds:

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security SIG. The Security SIG is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security Project. The Security SIG undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

[[File:SecurityProjectPillars.png|center|820px|A diagram showing the pillars of the Security project]]

== Organization and Contribution ==
The Security SIG is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack clouds! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, cross project collaboration, writing documentation or inventing cool new features and tooling - we want to hear from you!

==== IRC ====
The security SIG has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security SIG meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security SIG has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Anchor - Ephemeral PKI ===
Anchor is a lightweight, open source, Public Key Infrastructure (PKI), which uses automated provisioning of short-term certificates to enable cryptographic trust in OpenStack services. Certificates are typically valid for 12-24 hours and are issued based on the result from a policy enforcing decision engine. Short term certificates enable passive revocation, to bypass the issues with the traditional revocation mechanisms used in most PKI deployments.

* [https://git.openstack.org/cgit/openstack/anchor Anchor Git Repository]
* [https://review.openstack.org/#/q/anchor,n,z Anchor Gerrit]
* [https://bugs.launchpad.net/anchor Anchor Launchpad]
* [https://www.youtube.com/watch?v=jf_YOzW7I3s Summit Announcement Video]
* [https://www.youtube.com/watch?v=Q_ZhrQq-_YM Summit Followup Video]

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security SIG].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

== Advisory Activities ==
The Security SIG issues Security Notes targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it. The Security SIG works closely with the VMT assisting with feedback on various issues.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security SIG write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security SIG in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

Security-SIG

2018-02-26T10:44:50Z

Lhinds:

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security SIG. The Security SIG is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security Project. The Security SIG undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

[[File:SecurityProjectPillars.png|center|820px|A diagram showing the pillars of the Security project]]

== Organization and Contribution ==
The Security SIG is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack code! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, writing documentation or inventing cool new features and tooling - we want to hear from you!

==== IRC ====
The security SIG has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security SIG meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security SIG has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Anchor - Ephemeral PKI ===
Anchor is a lightweight, open source, Public Key Infrastructure (PKI), which uses automated provisioning of short-term certificates to enable cryptographic trust in OpenStack services. Certificates are typically valid for 12-24 hours and are issued based on the result from a policy enforcing decision engine. Short term certificates enable passive revocation, to bypass the issues with the traditional revocation mechanisms used in most PKI deployments.

* [https://git.openstack.org/cgit/openstack/anchor Anchor Git Repository]
* [https://review.openstack.org/#/q/anchor,n,z Anchor Gerrit]
* [https://bugs.launchpad.net/anchor Anchor Launchpad]
* [https://www.youtube.com/watch?v=jf_YOzW7I3s Summit Announcement Video]
* [https://www.youtube.com/watch?v=Q_ZhrQq-_YM Summit Followup Video]

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security SIG].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

== Advisory Activities ==
The Security SIG issues Security Notes targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it. The Security SIG works closely with the VMT assisting with feedback on various issues.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security SIG write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security SIG in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

Security-SIG

2018-02-26T10:44:25Z

Lhinds: Rename to SIG

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security SIG. The Security SIG is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security SIG. The Security SIG undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

[[File:SecurityProjectPillars.png|center|820px|A diagram showing the pillars of the Security project]]

== Organization and Contribution ==
The Security SIG is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack code! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, writing documentation or inventing cool new features and tooling - we want to hear from you!

==== IRC ====
The security SIG has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security SIG meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security SIG has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Anchor - Ephemeral PKI ===
Anchor is a lightweight, open source, Public Key Infrastructure (PKI), which uses automated provisioning of short-term certificates to enable cryptographic trust in OpenStack services. Certificates are typically valid for 12-24 hours and are issued based on the result from a policy enforcing decision engine. Short term certificates enable passive revocation, to bypass the issues with the traditional revocation mechanisms used in most PKI deployments.

* [https://git.openstack.org/cgit/openstack/anchor Anchor Git Repository]
* [https://review.openstack.org/#/q/anchor,n,z Anchor Gerrit]
* [https://bugs.launchpad.net/anchor Anchor Launchpad]
* [https://www.youtube.com/watch?v=jf_YOzW7I3s Summit Announcement Video]
* [https://www.youtube.com/watch?v=Q_ZhrQq-_YM Summit Followup Video]

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security SIG].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

== Advisory Activities ==
The Security SIG issues Security Notes targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it. The Security SIG works closely with the VMT assisting with feedback on various issues.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security SIG write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security SIG in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

Security-SIG

2018-02-26T10:39:07Z

Lhinds: Lhinds moved page Security to Security-SIG

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security project. The Security project is a horizontal effort within OpenStack that is comprised of what was previously referred to as the OpenStack Security Group and the Vulnerability Management Team. The Security project undertakes both technical and governance activities within OpenStack, aiming to provide guidance, information and code that enhances the overall security of the OpenStack ecosystem.

[[File:SecurityProjectPillars.png|center|820px|A diagram showing the pillars of the Security project]]

== Organization and Contribution ==
The security group is built up primarily of two groups of people; those who write OpenStack code and those who try to secure OpenStack code! We have contributors from over 30 different companies involved in OpenStack. If you're interested in helping to make OpenStack more secure, either through writing better code, writing documentation or inventing cool new features and tooling - we want to hear from you!

=== Organization ===
The Security project was recently incorporated as an official OpenStack team. That means we're recognised by the OpenStack foundation and we govern ourselves in the same way that every other official project does. We have a Project Technical Lead (PTL), Cores and Regular members just like other projects do. The PTL is elected every six months, we meet up at each OpenStack Summit and hold our own mid-cycle meet-ups too. More regularly we meet on IRC each week to discuss progress on multiple activities. We use the [Security] tag on the standard [[https://wiki.openstack.org/wiki/Mailing_Lists#Future_Development|OpenStack developer mailing list]] when things warrant wider discussion.

* [[https://wiki.openstack.org/wiki/Mailing_Lists#Future_Development|OpenStack developer mailing list]]

==== IRC ====
The security group has an IRC room (#openstack-security) on irc.freenode.net that's used for general communications, chat and the occasional user query. The security project meets weekly to discuss progress on individual activities. We encourage new contributors to say hello during our weekly meetings.

* [http://eavesdrop.openstack.org/#Security_meeting Weekly meeting IRC information]
* [http://eavesdrop.openstack.org/meetings/security/ Weekly meeting logs]
* [http://eavesdrop.openstack.org/irclogs/%23openstack-security/ Logs from the #openstack-security room]
* [https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 IRC WebChat Client]

=== Contribution ===
The process of becoming a member of the group is described on the OSSG [https://launchpad.net/~openstack-ossg Launchpad page].
At the moment of writing, there is no defined "procedure" to get involved into the OSSG and a suggested set of steps
follows. Each described steps might or not be relevant depending on the individual member's background and familiarity with the OpenStack project.

Some steps to get started are:
*Read the OpenStack documentation and understand the most common deployment scenarios.
*Go through the [https://docs.openstack.org/pike/install/ OpenStack installation guide] and create a deployment (either a native one or in a virtualized environment), in order to get a basic understanding of the interaction of the different OpenStack services. Some installation scripts such as [http://devstack.org/ Devstack] and [http://openstack.redhat.com/Quickstart Packstack] are readily available. However, you should not underestimate the educational benefits of spending some quality time to install OpenStack manually.
*Read the newly released [http://docs.openstack.org/trunk/openstack-security/content/index.html OpenStack security guide] in order to dive into the security aspects of setting up and running an OpenStack deployment.
*Getting acquainted to some degree with the rest of the OpenStack manuals is highly encouraged.
*The next step is to choose one of the OpenStack components in order to become closely familiarized with it and eventually be able to use the combined expertise of the OSSG in order to make thoughtful contributions to the component (code reviews, direct code contribution, architectural aspects) and improve its security. It is of course important to chose a component that would closely match your interests; given the size of OpenStack, becoming closely familiar with the chosen component's code base, deployment and administration practices might require significant time investments. Once you have chosen a component, send an email on the OSSG email list to let others know about your intentions.

See https://wiki.openstack.org/wiki/Security/How_To_Contribute for more details on how you can improve OpenStack security.

== Software Activities ==
The OpenStack Security Project has a number of ongoing activities that aim to enhance security of the OpenStack cloud ecosystem. These predominantly break down into three groups; Advisory, Guidance and Software.

=== Anchor - Ephemeral PKI ===
Anchor is a lightweight, open source, Public Key Infrastructure (PKI), which uses automated provisioning of short-term certificates to enable cryptographic trust in OpenStack services. Certificates are typically valid for 12-24 hours and are issued based on the result from a policy enforcing decision engine. Short term certificates enable passive revocation, to bypass the issues with the traditional revocation mechanisms used in most PKI deployments.

* [https://git.openstack.org/cgit/openstack/anchor Anchor Git Repository]
* [https://review.openstack.org/#/q/anchor,n,z Anchor Gerrit]
* [https://bugs.launchpad.net/anchor Anchor Launchpad]
* [https://www.youtube.com/watch?v=jf_YOzW7I3s Summit Announcement Video]
* [https://www.youtube.com/watch?v=Q_ZhrQq-_YM Summit Followup Video]

=== Bandit - Python Security Linter ===
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library. The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. Although early in development it is already adding value to the OpenStack code base with several projects leveraging it in their CI gate tests. As the project matures the desire is to see widespread adoption of Bandit in the OpenStack community.

Bandit can be obtained by cloning the repository. The README.rst file contains documentation regarding installation, usage, and configuration.

* [https://git.openstack.org/cgit/openstack/bandit Bandit Git Repository]
* [https://review.openstack.org/#/q/bandit,n,z Bandit Gerrit]
* [https://bugs.launchpad.net/bandit Bandit Launchpad]

=== Syntribos - Python API security testing tool===

Syntribos is an open source automated API security testing tool that is
maintained by members of the [https://wiki.openstack.org/wiki/Security OpenStack Security Project].

Given a simple configuration file and an example HTTP request, syntribos
can replace any API URL, URL parameter, HTTP header and request body
field with a given set of strings. Syntribos iterates through each position
in the request automatically. The tool aims to automatically detect common
security defects such as SQL injection, LDAP injection, buffer overflow, etc.
In addition, it can be used to help identify new security defects
by automated fuzzing.

Syntribos can be installed directly from [https://pypi.python.org/pypi/pip pypi with pip].

* [http://docs.openstack.org/developer/syntribos/ Syntribos developer documentation]
* [https://git.openstack.org/cgit/openstack/syntribos Syntribos Git Repository]
* [https://review.openstack.org/#/q/syntribos,n,z Syntribos Gerrit]
* [https://bugs.launchpad.net/syntribos Syntribos Launchpad]

== Advisory Activities ==
The Security project issues Security Advisories (OSSA) and Security Notes (OSSN) both are targeted at OpenStack Users and Vendors who either run or package OpenStack for use by downstream consumers.

=== Security Advisories - OSSA ===
[[File:VMTprocess.png|800px|thumbnail|center]]

Within the Security project exists the Vulnerability Management Team. The VMT is a small group of experienced developers who receive, triage and release fixes for vulnerabilities in OpenStack. The final stage of fixing a vulnerability is to release a Security Advisory for the community. The OSSA details the nature of the vulnerability and any workaround or patches required to mitigate it.

* Read more about the VMT process on [https://security.openstack.org/vmt-process.html their dedicated webpage]
* View the [https://security.openstack.org/ossalist.html issued OSSA list]

=== Security Notes - OSSN ===
Security Notes are designed to complement the Security Advisories issued by the Vulnerability Management Team. Security notes can be issued for almost anything affecting the security of potential OpenStack deployments. In many cases a vulnerability may be reported that cannot be fixed immediately because the fix might break the API or otherwise cause service-breaking issues for downstream consumers. Often the Security project will write notes that will guide deployers in how to best mitigate the issues when an OSSA cannot be provided. OSSNs are also issued for significant vulnerabilities in third party applications that would affect OpenStack deployments.

* [https://wiki.openstack.org/wiki/Security/Security_Note_Process OpenStack Security Note Process]
* [https://wiki.openstack.org/wiki/Security_Notes Issued Security Notes]

== Guidance Activities ==
Most of the documentation we produce, be it the security guide or security advisories are focussed on downstream consumers of OpenStack technology. We are also actively working on guidance and tooling for *developers* in the hope that we can help stop vulnerabilities making it into code in the first place.

See the [https://security.openstack.org/#secure-development-guidelines Developer Guideline] section of https://security.openstack.org for more info

=== Security Guide ===
[[File:Openstack-security-guide.jpg|frameless|center]]
This [http://docs.openstack.org/sec/ book] was written by a close community of security experts from the OpenStack Security Project in a short, intense week-long effort at an undisclosed location. One of the goals for this book is to bring together interested members to capture their collective knowledge and give it back to the OpenStack community.

See http://docs.openstack.org/sec/

=== Security Blog ===
We now have a blog, take a look to see the latest of what has been happening in the OpenStack Security world: https://openstack-security.github.io/

== Vulnerability Management Team ==
The OpenStack Vulnerability Management team is the first point of contact for OpenStack security issues. They are responsible for the vulnerability handling and disclosure process.

See http://wiki.openstack.org/VulnerabilityManagement

Security

2018-02-26T10:39:07Z

Lhinds: Lhinds moved page Security to Security-SIG

#REDIRECT [[Security-SIG]]

PTG/Rocky/Etherpads

2018-02-05T10:40:33Z

Lhinds: add security sig

__NOTOC__

This is the list of etherpads for the Projects Team Gathering in Dublin. Each team can organize the content on their allocated day(s) in the way that seems to most appropriate to them. We suspect most teams will avoid strict timeboxed slots and will use etherpads to list topics to cover. This page lists those etherpads for easy reference.

For more details on the event, see the [https://www.openstack.org/ptg/ event website].

Sign up for [https://docs.google.com/spreadsheets/d/1MK7rCgYXCQZP1AgQ0RUiuc-cEXIzW5RuRzz5BWhV4nQ/edit#gid=0 team video interviews].

For what's happening '''right now''' (during the event), see the [http://ptg.openstack.org/ptg.html ptgbot page].

'''Projects:'''
* Blazar - https://etherpad.openstack.org/p/blazar-ptg-rocky
* Cinder - https://etherpad.openstack.org/p/cinder-ptg-rocky
* Cyborg - https://etherpad.openstack.org/p/cyborg-ptg-rocky
* Docs/I18n - https://etherpad.openstack.org/p/docs-i18n-ptg-rocky
* Glance - https://etherpad.openstack.org/p/glance-rocky-ptg-planning
* Heat - https://etherpad.openstack.org/p/heat-rocky-ptg
* Horizon - https://etherpad.openstack.org/p/horizon-ptg-rocky
* Infra - https://etherpad.openstack.org/p/infra-rocky-ptg
* Ironic - https://etherpad.openstack.org/p/ironic-rocky-ptg
* Keystone - https://etherpad.openstack.org/p/keystone-rocky-ptg
* Kolla - https://etherpad.openstack.org/p/kolla-rocky-ptg-planning
* Kuryr - https://etherpad.openstack.org/p/kuryr-ptg-rocky
* Magnum - https://etherpad.openstack.org/p/magnum-ptg-rocky
* Manila - https://etherpad.openstack.org/p/manila-rocky-ptg
* Mistral - https://etherpad.openstack.org/p/mistral-ptg-rocky
* Monasca - https://etherpad.openstack.org/p/monasca-ptg-rocky
* Neutron - https://etherpad.openstack.org/p/neutron-ptg-rocky
* Nova - https://etherpad.openstack.org/p/nova-ptg-rocky
* Octavia - https://etherpad.openstack.org/p/octavia-ptg-rocky
* Oslo - https://etherpad.openstack.org/p/oslo-ptg-rocky
* QA - https://etherpad.openstack.org/p/qa-rocky-ptg
* RelMgt - https://etherpad.openstack.org/p/relmgt-ptg-rocky
* Sahara - https://etherpad.openstack.org/p/sahara-rocky-ptg
* Swift - https://etherpad.openstack.org/p/Dublin_PTG_Swift
* TripleO - https://etherpad.openstack.org/p/tripleo-ptg-rocky
* Vitrage - https://etherpad.openstack.org/p/vitrage-ptg-rocky
* Watcher - https://etherpad.openstack.org/p/rocky-watcher-ptg

'''SIG/Theme/Other:'''
* API SIG - https://etherpad.openstack.org/p/api-sig-ptg-rocky
* First Contact SIG - https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG
* Public Cloud WG - https://etherpad.openstack.org/p/publiccloud-wg-ptg-rocky
* Security SIG - https://etherpad.openstack.org/p/security-ptg-rocky

OSSN/OSSN-0068

2017-12-01T10:08:52Z

Lhinds: /* ip-user.cfg.xml */

__NOTOC__

== Repeated token revocation requests, can lead to service degradation or disruption ==

=== Summary ===
There is currently no limit to the frequency of keystone token revocations that
can be made by a single user, in any given time frame. If a user repeatedly
makes token requests, and then immediately revokes the token, a performance
degradation can occur and possible DoS (Denial of Service) attack could be
directed towards keystone.

=== Affected Services / Software ===
All services using keystone.
Mitaka, Liberty, Kilo, Nova, Juno, Havana, Icehouse, Grizzly, Folsom, Essex.

=== Discussion ===
Token revocation can be self-served, with no restrictions enforced on the
number of token revocations made by any user (including service users).

If token revocations are made in quick succession, response times starts to lengthen, due
to the increasing entries made in the revocation_event table.

With no form of rate limiting in place, a single user can cause the OpenStack
auth service to become poor in response time, resulting in a DoS style attack.

A cleanup of revocation events does occur, based on token expiration plus
expiration_buffer (which is 30 minutes by default). However, with the default
token TTL of 3600 seconds, a user can potentially fill up approximately several
thousand events during that time.

=== Recommended Actions ===
For current stable OpenStack releases (Mitaka and previous), operators are
recommended to deploy external rate-limiting proxies or web application firewalls, to
provide a front layer of protection to keystone.

The following solutions may be considered, however it is key that the operator
carefully plans and considers the individual performance needs of users
and services within their OpenStack cloud, when configuring any rate limiting
functionality.

==== Repose ====

===== Rate Limiting Filter =====
Repose provides a rate limiting filter, that can limit per IP address and
to a specific HTTP method (DELETE in relation to this OSSN).

The following config may be considered for a single node. For more complex
deployments, clusters can be constructed , utilizing a distributed data-store.

===== system-model.cfg.xml =====

<?xml version="1.0" encoding="UTF-8"?>
<system-model xmlns="<nowiki>http://docs.openrepose.org/repose/system-model/v2.0</nowiki>">
<repose-cluster id="repose">
<nodes>
<node id="repose_node1" hostname="localhost" http-port="8080"/>
</nodes>
<filters>
<filter name="ip-user"/>
<filter name="rate-limiting"/>
</filters>
<services>
</services>
<destinations>
<endpoint id="keystone" protocol="http" hostname="<nowiki>http://idenity-server.acme.com</nowiki>" root-path="/" port="35357" default="true"/>
</destinations>
</repose-cluster>
<phone-home enabled="false"
origin-service-id="your-service"
contact-email="your@service.com"/>
</system-model>

===== ip-user.cfg.xml =====

<?xml version="1.0" encoding="UTF-8"?>
<ip-user xmlns="<nowiki>http://docs.openrepose.org/repose/ip-user/v1.0</nowiki>">
<user-header name="X-PP-User" quality="0.4"/>
<group-header name="X-PP-Groups" quality="0.4"/>
<group name="ipv4-group">
<cidr-ip>192.168.0.0/24</cidr-ip>
</group>
<group name="match-all">
<cidr-ip>0.0.0.0/0</cidr-ip>
<cidr-ip>0::0/0</cidr-ip>
</group>
</ip-user>

* Note: Using the ip-user filter, will mean each IP address sending requests to repose, will have its own rate-limit bucket. Therefore any IP exceeding the limit, will be blocked - but only that IP. If you are sending NAT'ed connections to repose, then you should consider, they will also be seen as a single IP, and grouped accordingly.

===== rate-limiting.cfg.xml =====

<?xml version="1.0" encoding="UTF-8"?>
<rate-limiting xmlns="<nowiki>http://docs.openrepose.org/repose/rate-limiting/v1.0</nowiki>">
<request-endpoint uri-regex="/limits" include-absolute-limits="false"/>
<global-limit-group>
<limit id="global" uri="*" uri-regex=".*" value="1000" unit="MINUTE"/>
</global-limit-group>
<limit-group id="limited" groups="limited" default="true">
<limit id="all" uri="/auth/token" uri-regex="/.*" http-methods="DELETE" unit="MINUTE" value="10"/>
</limit-group>
<limit-group id="unlimited" groups="unlimited" default="false"/>
</rate-limiting>
</code>

Key points to note with the above. The rate limit is limited to DELETE
requests (which is the http method used to revoke a token), and to the URI
/auth/token. Any IP which exceeds 10 revoke requests per minute, will be blocked
for 1 minute.

Further details can be found on the openrepose wiki:

https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+filter

===Other possible solutions===

==== NGINX ====
NGINX provides the limit_req_module, which can be used to provide a global rate
limit. Using a map, it can be limited to just the DELETE method.

=====nginx.conf=====
http {
map $request_method $keystone {
default "";
DELETE $binary_remote_addr;
}
limit_req_zone $keystone zone=keystone:10m rate=10r/m;
server {
...
location /auth/token {
limit_req zone=keystone;
...
}
}

Further details can be found on the nginx site:

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

==== HAProxy ====

HAProxy can provide inherent rate-limiting, using stick-tables, with a General
Purpose Counter (gpc)

=====/etc/init.d/haproxy.cfg=====
# Monitors the number of request sent by an IP over a period of 10 seconds
stick-table type ip size 1m expire 10s store gpc0,http_req_rate(10s)
tcp-request connection track-sc1 src
tcp-request connection reject if { src_get_gpc0 gt 0 }

Further details can be found on the haproxy website:

http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos

==== Apache ====
A number of solutions can be explored here.

===== mod_ratelimit =====
http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

===== mod_qos =====
http://opensource.adnovum.ch/mod_qos/dos.html

===== mod_evasive =====
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7

===== mod_security =====
https://www.modsecurity.org/

==== Contacts / References ====
* Author: Luke Hinds, Red Hat
* This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0068
* Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1553324
* OpenStack Security ML : openstack-security@lists.openstack.org
* OpenStack Security Group : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0068

2017-12-01T10:08:24Z

Lhinds: /* Summary */

__NOTOC__

== Repeated token revocation requests, can lead to service degradation or disruption ==

=== Summary ===
There is currently no limit to the frequency of keystone token revocations that
can be made by a single user, in any given time frame. If a user repeatedly
makes token requests, and then immediately revokes the token, a performance
degradation can occur and possible DoS (Denial of Service) attack could be
directed towards keystone.

=== Affected Services / Software ===
All services using keystone.
Mitaka, Liberty, Kilo, Nova, Juno, Havana, Icehouse, Grizzly, Folsom, Essex.

=== Discussion ===
Token revocation can be self-served, with no restrictions enforced on the
number of token revocations made by any user (including service users).

If token revocations are made in quick succession, response times starts to lengthen, due
to the increasing entries made in the revocation_event table.

With no form of rate limiting in place, a single user can cause the OpenStack
auth service to become poor in response time, resulting in a DoS style attack.

A cleanup of revocation events does occur, based on token expiration plus
expiration_buffer (which is 30 minutes by default). However, with the default
token TTL of 3600 seconds, a user can potentially fill up approximately several
thousand events during that time.

=== Recommended Actions ===
For current stable OpenStack releases (Mitaka and previous), operators are
recommended to deploy external rate-limiting proxies or web application firewalls, to
provide a front layer of protection to keystone.

The following solutions may be considered, however it is key that the operator
carefully plans and considers the individual performance needs of users
and services within their OpenStack cloud, when configuring any rate limiting
functionality.

==== Repose ====

===== Rate Limiting Filter =====
Repose provides a rate limiting filter, that can limit per IP address and
to a specific HTTP method (DELETE in relation to this OSSN).

The following config may be considered for a single node. For more complex
deployments, clusters can be constructed , utilizing a distributed data-store.

===== system-model.cfg.xml =====

<?xml version="1.0" encoding="UTF-8"?>
<system-model xmlns="<nowiki>http://docs.openrepose.org/repose/system-model/v2.0</nowiki>">
<repose-cluster id="repose">
<nodes>
<node id="repose_node1" hostname="localhost" http-port="8080"/>
</nodes>
<filters>
<filter name="ip-user"/>
<filter name="rate-limiting"/>
</filters>
<services>
</services>
<destinations>
<endpoint id="keystone" protocol="http" hostname="<nowiki>http://idenity-server.acme.com</nowiki>" root-path="/" port="35357" default="true"/>
</destinations>
</repose-cluster>
<phone-home enabled="false"
origin-service-id="your-service"
contact-email="your@service.com"/>
</system-model>

===== ip-user.cfg.xml =====

<?xml version="1.0" encoding="UTF-8"?>
<ip-user xmlns="<nowiki>http://docs.openrepose.org/repose/ip-user/v1.0</nowiki>">
<user-header name="X-PP-User" quality="0.4"/>
<group-header name="X-PP-Groups" quality="0.4"/>
<group name="ipv4-group">
<cidr-ip>192.168.0.0/24</cidr-ip>
</group>
<group name="match-all">
<cidr-ip>0.0.0.0/0</cidr-ip>
<cidr-ip>0::0/0</cidr-ip>
</group>
</ip-user>

* Note: Using the ip-user filter, will mean each IP address sending requests to
repose, will have its own rate-limit bucket. Therefore any IP exceeding the
limit, will be blocked - but only that IP. If you are sending NAT'ed connections
to repose, then you should consider, they will also be seen as a single IP, and
grouped accordingly.

===== rate-limiting.cfg.xml =====

<?xml version="1.0" encoding="UTF-8"?>
<rate-limiting xmlns="<nowiki>http://docs.openrepose.org/repose/rate-limiting/v1.0</nowiki>">
<request-endpoint uri-regex="/limits" include-absolute-limits="false"/>
<global-limit-group>
<limit id="global" uri="*" uri-regex=".*" value="1000" unit="MINUTE"/>
</global-limit-group>
<limit-group id="limited" groups="limited" default="true">
<limit id="all" uri="/auth/token" uri-regex="/.*" http-methods="DELETE" unit="MINUTE" value="10"/>
</limit-group>
<limit-group id="unlimited" groups="unlimited" default="false"/>
</rate-limiting>
</code>

Key points to note with the above. The rate limit is limited to DELETE
requests (which is the http method used to revoke a token), and to the URI
/auth/token. Any IP which exceeds 10 revoke requests per minute, will be blocked
for 1 minute.

Further details can be found on the openrepose wiki:

https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+filter

===Other possible solutions===

==== NGINX ====
NGINX provides the limit_req_module, which can be used to provide a global rate
limit. Using a map, it can be limited to just the DELETE method.

=====nginx.conf=====
http {
map $request_method $keystone {
default "";
DELETE $binary_remote_addr;
}
limit_req_zone $keystone zone=keystone:10m rate=10r/m;
server {
...
location /auth/token {
limit_req zone=keystone;
...
}
}

Further details can be found on the nginx site:

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

==== HAProxy ====

HAProxy can provide inherent rate-limiting, using stick-tables, with a General
Purpose Counter (gpc)

=====/etc/init.d/haproxy.cfg=====
# Monitors the number of request sent by an IP over a period of 10 seconds
stick-table type ip size 1m expire 10s store gpc0,http_req_rate(10s)
tcp-request connection track-sc1 src
tcp-request connection reject if { src_get_gpc0 gt 0 }

Further details can be found on the haproxy website:

http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos

==== Apache ====
A number of solutions can be explored here.

===== mod_ratelimit =====
http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

===== mod_qos =====
http://opensource.adnovum.ch/mod_qos/dos.html

===== mod_evasive =====
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7

===== mod_security =====
https://www.modsecurity.org/

==== Contacts / References ====
* Author: Luke Hinds, Red Hat
* This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0068
* Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1553324
* OpenStack Security ML : openstack-security@lists.openstack.org
* OpenStack Security Group : https://launchpad.net/~openstack-ossg

Security SIG

2017-11-23T10:06:38Z

Lhinds: Initial page bootstrap

== Security SIG [Work in Progress] ==

----

'''Status''': Not Active

OSSN/OSSN-0081

2017-10-27T08:21:04Z

Lhinds: /* Contacts / References */

__NOTOC__

== sha512_crypt is insufficient for password hashing ==

=== Summary ===

Use of sha512_crypt for password hashing in versions of Keystone prior to Pike, is insufficient and provides limited protection against brute-forcing of password hashes.

=== Affected Services / Software ===

OpenStack Identity Service (Keystone). OpenStack Releases Ocata, Newton.

=== Discussion ===

Keystone uses sha512_crypt for password hashing. This provides insufficient and limited protection, since sha512_crypt algorithm has a low computational cost factor, therefore making it easier to crack passwords offline in a short period of time.

The correct mechanism is to use the more secure hashing algorithms with a higher computational cost factor such as bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt.

=== Recommended Actions ===

It is recommended that operators upgrade to the Pike release where all future passwords would be bcrypt hashed.

Operators should also force password changes on all users [1], which will result in the users newly generated passwords being bcrypt hashed.

=== Contacts / References ===

Author: Luke Hinds, Red Hat

[1]: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#force-users-to-change-password-upon-first-use

[2] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0081

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1668503

Mailing List : [Security] tag on openstack-dev@lists.openstack.org

OpenStack Security Project : https://launchpad.net/~openstack-ossg

Security Notes

2017-10-04T15:45:30Z

Lhinds: /* Published Security Notes */

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0082|OSSN-0082]] - Heap and Stack based buffer overflows in dnsmasq prior to version 2.78
* [[OSSN/OSSN-0081|OSSN-0081]] - Reserved sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing
* [[OSSN/OSSN-0080|OSSN-0080]] - Aodh can be used to launder Keystone trusts
* [[OSSN/OSSN-0079|OSSN-0079]] - Ceph credentials included in logs using older libvirt/qemu
* [[OSSN/OSSN-0078|OSSN-0078]] - copy_from in Image Service API v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

OSSN/OSSN-0082

2017-10-04T15:45:13Z

Lhinds: /* Contacts / References */

__NOTOC__

== Heap and Stack based buffer overflows in dnsmasq prior to version 2.78 ==

=== Summary ===

A series of heap and stack based buffer overflows have been discovered in versions of dnsmasq prior to release 2.78.

=== Affected Services / Software ===

Any neutron based OpenStack deployment on a version of dnsmasq prior to
2.78.

=== Discussion ===

The following attack vectors have been assigned the following CVE numbers.

* CVE-2017-14491
* CVE-2017-14492
* CVE-2017-14493
* CVE-2017-14494
* CVE-2017-14495
* CVE-2017-14496
* CVE-2017-13704

Each of these CVE's exposes a neutron based OpenStack deployment to various attacks such as leakage of sensitive memory information or causing a denial of service. Nodes are exposed to this risk by the crafting of various nefarious DNS or DHCP requests.

=== Recommended Actions ===

Operators should update the dnsmasq service using the affected nodes operating systems packaging tools to version 2.78 and later, or a distribution packaged version that contains relevant backports for these vulnerabilities.

=== Contacts / References ===

Author: Luke Hinds, Red Hat

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0082

Original Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1721063

Mailing List : [Security] tag on openstack-dev@lists.openstack.org

OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0082

2017-10-04T15:45:03Z

Lhinds: /* Discussion */

__NOTOC__

== Heap and Stack based buffer overflows in dnsmasq prior to version 2.78 ==

=== Summary ===

A series of heap and stack based buffer overflows have been discovered in versions of dnsmasq prior to release 2.78.

=== Affected Services / Software ===

Any neutron based OpenStack deployment on a version of dnsmasq prior to
2.78.

=== Discussion ===

The following attack vectors have been assigned the following CVE numbers.

* CVE-2017-14491
* CVE-2017-14492
* CVE-2017-14493
* CVE-2017-14494
* CVE-2017-14495
* CVE-2017-14496
* CVE-2017-13704

Each of these CVE's exposes a neutron based OpenStack deployment to various attacks such as leakage of sensitive memory information or causing a denial of service. Nodes are exposed to this risk by the crafting of various nefarious DNS or DHCP requests.

=== Recommended Actions ===

Operators should update the dnsmasq service using the affected nodes operating systems packaging tools to version 2.78 and later, or a distribution packaged version that contains relevant backports for these vulnerabilities.

=== Contacts / References ===

Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0082
Original Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1721063
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0082

2017-10-04T15:44:50Z

Lhinds: /* Discussion */

__NOTOC__

== Heap and Stack based buffer overflows in dnsmasq prior to version 2.78 ==

=== Summary ===

A series of heap and stack based buffer overflows have been discovered in versions of dnsmasq prior to release 2.78.

=== Affected Services / Software ===

Any neutron based OpenStack deployment on a version of dnsmasq prior to
2.78.

=== Discussion ===

The following attack vectors have been assigned the following CVE numbers.

* CVE-2017-14491
* CVE-2017-14492
* CVE-2017-14493
* CVE-2017-14494
* CVE-2017-14495
* CVE-2017-14496
* CVE-2017-13704

Each of these CVE's exposes a neutron based OpenStack deployment to various attacks such as leakage of sensitive memory information or causing a denial of service. Nodes are exposed to this risk by the crafting of various nefarious DNS or DHCP requests.

=== Recommended Actions ===

Operators should update the dnsmasq service using the affected nodes operating systems packaging tools to version 2.78 and later, or a distribution packaged version that contains relevant backports for these vulnerabilities.

=== Contacts / References ===

Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0082
Original Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1721063
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0082

2017-10-04T15:44:25Z

Lhinds: Created page with "__NOTOC__ == Heap and Stack based buffer overflows in dnsmasq prior to version 2.78 == === Summary === A series of heap and stack based buffer overflows have been discovere..."

__NOTOC__

== Heap and Stack based buffer overflows in dnsmasq prior to version 2.78 ==

=== Summary ===

A series of heap and stack based buffer overflows have been discovered in versions of dnsmasq prior to release 2.78.

=== Affected Services / Software ===

Any neutron based OpenStack deployment on a version of dnsmasq prior to
2.78.

=== Discussion ===

Any neutron based OpenStack deployment on a version of dnsmasq prior to
2.78.

### Discussion ###
The following attack vectors have been assigned the following CVE numbers.

* CVE-2017-14491
* CVE-2017-14492
* CVE-2017-14493
* CVE-2017-14494
* CVE-2017-14495
* CVE-2017-14496
* CVE-2017-13704

Each of these CVE's exposes a neutron based OpenStack deployment to various attacks such as leakage of sensitive memory information or causing a denial of service. Nodes are exposed to this risk by the crafting of various nefarious DNS or DHCP requests.

=== Recommended Actions ===

Operators should update the dnsmasq service using the affected nodes operating systems packaging tools to version 2.78 and later, or a distribution packaged version that contains relevant backports for these vulnerabilities.

=== Contacts / References ===

Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0082
Original Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1721063
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0081

2017-09-17T11:25:02Z

Lhinds:

__NOTOC__

== sha512_crypt is insufficient for password hashing ==

=== Summary ===

Use of sha512_crypt for password hashing in versions of Keystone prior to Pike, is insufficient and provides limited protection against brute-forcing of password hashes.

=== Affected Services / Software ===

OpenStack Identity Service (Keystone). OpenStack Releases Ocata, Newton.

=== Discussion ===

Keystone uses sha512_crypt for password hashing. This provides insufficient and limited protection, since sha512_crypt algorithm has a low computational cost factor, therefore making it easier to crack passwords offline in a short period of time.

The correct mechanism is to use the more secure hashing algorithms with a higher computational cost factor such as bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt.

=== Recommended Actions ===

It is recommended that operators upgrade to the Pike release where all future passwords would be bcrypt hashed.

Operators should also force password changes on all users [1], which will result in the users newly generated passwords being bcrypt hashed.

=== Contacts / References ===

Author: Luke Hinds, Red Hat
[1]: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#force-users-to-change-password-upon-first-use
[2] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0081
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1668503
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg

Security/Projects/Bandit

2017-09-01T16:08:42Z

Lhinds: added luke and gage

==Overview==
Bandit is a security linter for Python source code, utilizing the [https://docs.python.org/2/library/ast.html ast] module from the Python standard library.

The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.

Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. As it matures and is proven to be useful, we see it being a possible addition to OpenStack CI gate tests with non-voting and eventually voting capabilities.

Bandit can be obtained by cloning the repository at <nowiki>https://git.openstack.org/openstack/bandit.git</nowiki>. The [http://git.openstack.org/cgit/openstack/bandit/tree/README.rst README.rst] file contains documentation regarding installation, usage, and configuration.

There is [https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/securing-the-openstack-code-base-with-bandit a video of bandit being presented at the OpenStack 2015 Summit in Vancouver].

==Contributing==
Bandit makes use of the OpenStack CI infrastructure provided through OpenStack:
* Read-only OpenStack git repository: [https://github.com/openstack/bandit https://github.com/openstack/bandit]
* Browsable OpenStack git repository: [https://git.openstack.org/cgit/openstack/bandit/ https://git.openstack.org/cgit/openstack/bandit/]
* Launchpad bug reporting and tracking: https://launchpad.net/bandit
* Gerrit endpoint for git repository: ssh://[username]@review.openstack.org:29418/openstack/bandit.git
* Gerrit reviews: [https://review.openstack.org/#/q/project:openstack/bandit,n,z https://review.openstack.org/#/q/project:openstack/bandit,n,z]

An easy way to contribute is to write a plugin/test that will allow Bandit to identify more security issues. Extensions and improvements to the underlying framework are also welcomed, although we'll be attempting to maintain stability in the interface that is presented to plugins.

See [http://docs.openstack.org/infra/manual/developers.html#development-workflow Development Workflow] for information on the general contribution/review workflow.

==Gate Testing with Bandit==
Bandit can help maintain the security of OpenStack projects when it's used as a gate test. Projects such as [http://docs.openstack.org/developer/keystone/ Keystone] have created a gate test which runs Bandit to ensure that common security code mistakes are not introduced when code is modified. New: you now have two ways to set up a Bandit gate and we'll cover the steps for both below.

===Full run Bandit gate:===
This option works well for projects that already have clean Bandit runs. To set up a full run Bandit gate for an OpenStack project, follow these steps:

# Add '''bandit''' (the package name on pypi) to the '''test-requirements.txt''' file. See [http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt global-requirements.txt] and copy the bandit line. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot.
# We need to have bandit in 2 tox environments: A '''bandit''' env that's used by the bandit team for integration tests, and the '''pep8''' env. See [http://git.openstack.org/cgit/openstack/keystone/tree/tox.ini Keystone's] for an example.

The following is a good starting point:

# B105-B107: hardcoded password checks - likely to generate false positives in a gate environment
# B401: import subprocess - not necessarily a security issue; this plugin is mainly used for penetration testing workflow
# B603,B606: process without shell - not necessarily a security issue; this plugin is mainly used for penetration testing workflow
# B607: start process with a partial path - this should be a project level decision
bandit -r ''project'' -x tests -s B105,B106,B107,B404,B603,B606,B607

Test this by running '''tox -e pep8'''. Initially, there will likely be several other tests that fail. Exclude these and work on fixing them in separate commits.

If you have any questions or comments please contact tmcpeak or tkelsey in #openstack-security on Freenode IRC.

===Bandit Baseline Gate===
This is the best option for projects which may have some legacy Bandit findings. Just because a project has some pre-existing security issues doesn't mean Bandit can't help prevent new ones! To set up a Bandit Baseline gate for an OpenStack project, follow these steps:

# Decide on the appropriate tests to run, not every test supported by bandit will be a good fit for every project. The bandit command line arguments -s and -t can be used to filter the test set to run.
# (optional) Add a Bandit config for your project. If you need to configure specific test parameters, in addition to switching tests on or off wholesale, then a bandit config may be needed. Bandit ships with the tool 'bandit-config-generator' that can help generate a config file if needed. This config is completely optional and is only needed if the defaults for specific tests are not sufficient.
# Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot.
# Add a tox environment to run the Bandit basline. To do this we'll add two targets:
##a standalone target "codesec" [https://github.com/openstack/bandit/blob/master/tox.ini#L31-L35 codesec tox target] which is useful for developers to check their changes
##a "linters" target: [https://github.com/openstack/bandit/blob/master/tox.ini#L18-L23 linters tox target]. By adding a linters target, we're extending our linters to run Bandit in addition to the normal flake8 tests.
## In both cases the arguments for 'bandit-baseline' should be identical to what you want to pass into Bandit. For example, if you created a config file above, you'll want to specify it with '-c myconfig.yaml'. In the example above we're running: 'bandit-baseline -r bandit -ll -ii' which tells Bandit (and bandit-baseline) to run scan the 'bandit' directory recursively and filter medium+ severity and confidence issues.
# Change the OpenStack infra zuul/layout.yaml for your project to use 'python-jobs-linters' instead of 'python-jobs' like we did for the Bandit project itself here: [https://review.openstack.org/#/c/260135/5/zuul/layout.yaml zuul layout change example]. This enables your project to use the 'linters' target in your python-jobs gate instead of just flake8. Note: if you do this you'll have a voting Bandit gate. You should make sure you're comfortable with Bandit and how it works before changing this.

==Per-task Configurations==
By default Bandit runs all plugins that it finds in the plugins directory. While this may be useful for doing a thorough manual review, for use cases such as automation and gate testing, this is probably overkill. When it is desirable to create specific sets of tests for specific tasks you should create a config file file for each task. This file can control the list of tests that should be run as well as tuning any parameters relevant to those tests. Once a custom config has been created, you can run it by using the "-c" command line option to point to the config file. Another way to control the tests that are run is to use the -t and -s command line options to select a set of tests, this is normally more convenient than using a full blown config when test parameters don't need refining.

==TODO==
TODO is now tracked using blueprints in Launchpad: https://blueprints.launchpad.net/bandit

==Projects using bandit==
{| class="wikitable sortable"
|-
! Project name !! Status
|-
| anchor ||
experimental
|-
| cinder ||
non-voting
|-
| designate ||
non-voting
|-
| keystone ||
voting
|-
| keystonemiddleware ||
voting
|-
| octavia ||
voting
|-
| python-keystoneclient ||
voting
|-
| swauth ||
voting
|}

==Team==
Bandit is a tool from the [https://security.openstack.org OpenStack Security] project.

Core project team:
* Jamie Finnigan (chair6)
* Travis McPeak (tmcpeak)
* Tim Kelsey (tkelsey)
* Eric Brown (browne)
* Ian Cordasco (sigmavirus24)
* Stan Pitucha (viraptor)
* Luke Hinds (lhinds)
* Gage Hugo (gagehugo)

Security Notes

2017-09-01T11:00:03Z

Lhinds:

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0082|OSSN-0082]] - Reserved get_identity_providers policy should be singular
* [[OSSN/OSSN-0081|OSSN-0081]] - Reserved sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing
* [[OSSN/OSSN-0080|OSSN-0080]] - Aodh can be used to launder Keystone trusts
* [[OSSN/OSSN-0079|OSSN-0079]] - Ceph credentials included in logs using older libvirt/qemu
* [[OSSN/OSSN-0078|OSSN-0078]] - copy_from in Image Service API v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

OSSN/OSSN-0081

2017-08-30T14:34:31Z

Lhinds: Created page with "reserved"

reserved

Security Notes

2017-08-30T14:23:41Z

Lhinds: added 81 & 82

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0082|OSSN-0082]] - Reserved get_identity_providers policy should be singular
* [[OSSN/OSSN-0081|OSSN-0081]] - Reserved sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing
* [[OSSN/OSSN-0080|OSSN-0080]] - Reserved for embargoed note.
* [[OSSN/OSSN-0079|OSSN-0079]] - Ceph credentials included in logs using older libvirt/qemu
* [[OSSN/OSSN-0078|OSSN-0078]] - copy_from in Image Service API v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

OSSN/OSSN-0080

2017-08-17T10:59:27Z

Lhinds:

__NOTOC__

== Aodh can be used to launder Keystone trusts ==

=== Summary ===

When adding an alarm action with the scheme `trust+http:` Aodh does not
verify that the user creating the alarm is the trustor or has the same
rights as the trustor, nor that the trust is for the same project as the
alarm.

=== Affected Services / Software ===

Aodh, the alarm engine of the Telemetry project.

Pike, Ocata and Newton

=== Discussion ===

When adding an alarm action with the scheme `trust+http:`, Aodh allows
the user to provide a trust ID to acquire a token with which to make a
webhook request. (If no trust ID is provided then Aodh creates a trust
internally, in which case the issue is not present.) However, Aodh makes
no attempt to verify that the user creating the alarm is the trustor or
has the same rights as the trustor - it also does not attempt to check
that the trust is for the same project as the alarm.

The nature of the `trust+http:` alarm notifier is that it allows the
user to obtain a token given the ID of a trust for which Aodh is the
trustee, since the URL is arbitrary and not limited to services in the
Keystone catalog.

=== Recommended Actions ===

A patchfile is attached to the launchpad referenced below. It will block use of trust URLs which contain trust ID's and log an error message of "trust URL cannot contain a trust ID.". Any trust action without a trust ID will result in Aodh internally creating a trust ID as before.

You will also need to restart the web server used for Aodh API. This is
typically apache. In cases of eventlet (in older versions) it will
require restart openstack-aodh-api for centos/RHEL/Suse and aodh-api
for ubuntu.

The fix has also been merged to master (Pike), Ocata and Newton.

=== Contacts / References ===
Discoverer: Zane Bitter, Red Hat

Author: Luke Hinds, Red Hat

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0080

CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12440

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1649333

OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0080

2017-08-17T10:58:04Z

Lhinds:

__NOTOC__

== Aodh can be used to launder Keystone trusts ==

=== Summary ===

When adding an alarm action with the scheme `trust+http:` Aodh does not
verify that the user creating the alarm is the trustor or has the same
rights as the trustor, not that the trust is for the same project as the
alarm.

=== Affected Services / Software ===

Aodh, the alarm engine of the Telemetry project.

Pike, Ocata and Newton

=== Discussion ===

When adding an alarm action with the scheme `trust+http:`, Aodh allows
the user to provide a trust ID to acquire a token with which to make a
webhook request. (If no trust ID is provided then Aodh creates a trust
internally, in which case the issue is not present.) However, Aodh makes
no attempt to verify that the user creating the alarm is the trustor or
has the same rights as the trustor - it also does not attempt to check
that the trust is for the same project as the alarm.

The nature of the `trust+http:` alarm notifier is that it allows the
user to obtain a token given the ID of a trust for which Aodh is the
trustee, since the URL is arbitrary and not limited to services in the
Keystone catalog.

=== Recommended Actions ===

A patchfile is attached to the launchpad referenced below. It will block use of trust URLs which contain trust ID's and log an error message of "trust URL cannot contain a trust ID.". Any trust action without a trust ID will result in Aodh internally creating a trust ID as before.

You will also need to restart the web server used for Aodh API. This is
typically apache. In cases of eventlet (in older versions) it will
require restart openstack-aodh-api for centos/RHEL/Suse and aodh-api
for ubuntu.

The fix has also been merged to master (Pike), Ocata and Newton.

=== Contacts / References ===
Discoverer: Zane Bitter, Red Hat

Author: Luke Hinds, Red Hat

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0080

CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12440

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1649333

OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0080

2017-08-17T10:57:38Z

Lhinds: Created page with "__NOTOC__ Aodh can be used to launder Keystone trusts --- === Summary === When adding an alarm action with the scheme `trust+http:` Aodh does not verify that the user creat..."

__NOTOC__

Aodh can be used to launder Keystone trusts
---

=== Summary ===

When adding an alarm action with the scheme `trust+http:` Aodh does not
verify that the user creating the alarm is the trustor or has the same
rights as the trustor, not that the trust is for the same project as the
alarm.

=== Affected Services / Software ===

Aodh, the alarm engine of the Telemetry project.

Pike, Ocata and Newton

=== Discussion ===

When adding an alarm action with the scheme `trust+http:`, Aodh allows
the user to provide a trust ID to acquire a token with which to make a
webhook request. (If no trust ID is provided then Aodh creates a trust
internally, in which case the issue is not present.) However, Aodh makes
no attempt to verify that the user creating the alarm is the trustor or
has the same rights as the trustor - it also does not attempt to check
that the trust is for the same project as the alarm.

The nature of the `trust+http:` alarm notifier is that it allows the
user to obtain a token given the ID of a trust for which Aodh is the
trustee, since the URL is arbitrary and not limited to services in the
Keystone catalog.

=== Recommended Actions ===

A patchfile is attached to the launchpad referenced below. It will block use of trust URLs which contain trust ID's and log an error message of "trust URL cannot contain a trust ID.". Any trust action without a trust ID will result in Aodh internally creating a trust ID as before.

You will also need to restart the web server used for Aodh API. This is
typically apache. In cases of eventlet (in older versions) it will
require restart openstack-aodh-api for centos/RHEL/Suse and aodh-api
for ubuntu.

The fix has also been merged to master (Pike), Ocata and Newton.

=== Contacts / References ===
Discoverer: Zane Bitter, Red Hat

Author: Luke Hinds, Red Hat

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0080

CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12440

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1649333

OpenStack Security Project : https://launchpad.net/~openstack-ossg

Security Notes

2017-08-04T15:03:44Z

Lhinds:

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0080|OSSN-0080]] - Reserved for embargoed note.
* [[OSSN/OSSN-0079|OSSN-0079]] - Ceph credentials included in logs using older libvirt/qemu
* [[OSSN/OSSN-0078|OSSN-0078]] - copy_from in Image Service API v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

Security Notes

2017-07-21T09:26:49Z

Lhinds:

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0079|OSSN-0079]] - Ceph credentials included in logs using older libvirt/qemu Edit
* [[OSSN/OSSN-0078|OSSN-0078]] - copy_from in Image Service API v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

OSSN/OSSN-0079

2017-07-21T09:26:33Z

Lhinds:

__NOTOC__

== Ceph credentials included in logs using older versions of libvirt/qemu ==

=== Summary ===
Older versions of libvirt included network storage authentication
information on the qemu command line. If libvirt raises an exception
which logs the qemu command line it used, for example an error starting
a domain, this authentication information will available in the logs.

=== Affected Services / Software ===
Versions 2.5 and earlier of QEMU and libvirt versions of 2.1 or earlier.

The issue has been resolved in all QEMU versions 2.6 and above and
libvirt 2.2 and above.

No patches or specific releases of Nova or Ceph are required, the
issue is completely resolved in QEMU and libvirt.

=== Discussion ===
If a deployment is using ceph, a libvirt error starting a domain would
log the cephx secret key and the monitor addresses on the qemu command
line.

A local attacker could then use this flaw to gain access of the cephx
secret key and perform certain privileged operations within the cluster.

An existing CVE is already present for this issue.

=== Recommended Actions ===
The issue has been resolved upstream. Users running qemu version 2.6 or
later, and libvirt version 2.2 or later, are not vulnerable.

No change is required in Nova or Ceph to resolve this issue.

=== Contacts / References ===
Author: Luke Hinds, Red Hat

https://access.redhat.com/security/cve/CVE-2015-5160

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0079

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1686743

OpenStack Security Project : https://launchpad.net/~openstack-ossg

OSSN/OSSN-0079

2017-07-18T09:38:34Z

Lhinds: Created page with "wip https://bugs.launchpad.net/ossn/+bug/1686743"

wip https://bugs.launchpad.net/ossn/+bug/1686743

Security Notes

2017-07-18T09:38:21Z

Lhinds:

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0079|OSSN-0079]] - [WIP] Ceph credentials included in logs using older libvirt/qemu Edit
* [[OSSN/OSSN-0078|OSSN-0078]] - copy_from in Image Service API v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

OSSN/OSSN-0078

2017-03-16T10:33:53Z

Lhinds:

__NOTOC__

== copy_from in Image Service API v1 allows network port scan ==

=== Summary ===
The `copy_from` feature in Image Service API v1 supplied by Glance can
allow an attacker to perform masked network port scans.

=== Affected Services / Software ===
Version 1 of the Glance Image Service (deprecated in Newton).

=== Discussion ===
In Version 1 of the Glance Image Service API it is possible to create
images with a URL such as `http://localhost:22`. This could then allow
an attacker to enumerate internal network details while appearing
masked, since the scan would appear to originate from the Glance image
service.

=== Recommended Actions ===
Version 1 of the Glance Image Service API was deprecated in the Newton
cycle, so operators should upgrade to a later version that will allow
use of Version 2.

Existing deployments can limit policy on `copy_from` by restricting use
to `admin` within `policy.json` as follows:

"copy_from": "role:admin"

=== Contacts / References ===
Author: Luke Hinds, Red Hat

This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0078

Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1606495

OpenStack Security Project : https://launchpad.net/~openstack-ossg

Security Notes

2017-03-16T10:29:14Z

Lhinds:

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0078|OSSN-0078]] - copy_from in Image Service API v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

Security Notes

2017-03-11T16:05:01Z

Lhinds: /* Published Security Notes */

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

Security Notes

2017-03-11T16:04:39Z

Lhinds: /* Published Security Notes */

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0078|OSSN-0078]] - [PENDING] Copy_from in api v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova metadata service should not be used for sensitive information
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

Security Notes

2017-03-11T16:03:24Z

Lhinds: /* Published Security Notes */

The OpenStack Security Project (OSSP) 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.

For advice on how to write OpenStack Security Notes see the [[Security/Security_Note_Process|Security Note Process]] documentation.

=== Published Security Notes ===
* [[OSSN/OSSN-0078|OSSN-0078]] - [PENDING] Copy_from in api v1 allows network port scan
* [[OSSN/OSSN-0076|OSSN-0076]] - Glance Image service v1 and v2 api image-create vulnerability
* [[OSSN/OSSN-0075|OSSN-0075]] - Deleted Glance image IDs may be reassigned
* [[OSSN/OSSN-0074|OSSN-0074]] - Nova embargoed issue (work in progress)
* [[OSSN/OSSN-0073|OSSN-0073]] - Horizon dashboard leaks internal information through cookies
* [[OSSN/OSSN-0070|OSSN-0070]] - Bandit versions lower than 1.1.0 do not escape HTML in issue reports
* [[OSSN/OSSN-0069|OSSN-0069]] - Host OS exposed to tenant networks via IPv6
* [[OSSN/OSSN-0068|OSSN-0068]] - Repeated token revocation requests, can lead to service degradation or disruption
* [[OSSN/OSSN-0067|OSSN-0067]] - Barbican server discloses SQL password and X-auth token values via LOG.debug ("work in progress")
* [[OSSN/OSSN-0066|OSSN-0066]] - MongoDB guest instance allows any user to connect
* [[OSSN/OSSN-0065|OSSN-0065]] - Users of Glance may be able to replace active image data
* [[OSSN/OSSN-0064|OSSN-0064]] - Keystone 'Admin_Token' in default configuration leads to insecure operation
* [[OSSN/OSSN-0063|OSSN-0063]] - Nova and Cinder key manager for Barbican misuses cached credentials (9 Jun 2016)
* [[OSSN/OSSN-0062|OSSN-0062]] - Potential reuse of revoked Identity tokens (15 Dec 2015)
* [[OSSN/OSSN-0061|OSSN-0061]] - Glance image signature uses an insecure hash algorithm (MD5) (15 Dec 2015)
* [[OSSN/OSSN-0060|OSSN-0060]] - Glance configuration option can lead to privilege escalation (25 Jan 2016)
* [[OSSN/OSSN-0059|OSSN-0059]] - Trusted vm can be powered on untrusted host (16 Nov 2015)
* [[OSSN/OSSN-0058|OSSN-0058]] - Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes (17 Sep 2015)
* [[OSSN/OSSN-0057|OSSN-0057]] - DoS style attack on Glance service can lead to service interruption or disruption (15 Oct 2015)
* [[OSSN/OSSN-0056|OSSN-0056]] - Cached keystone tokens may be accepted after revocation (17 Sep 2015)
* [[OSSN/OSSN-0055|OSSN-0055]] - Service accounts may have cloud admin privileges (17 Sep 2015)
* [[OSSN/OSSN-0054|OSSN-0054]] - Potential Denial of Service in Horizon login (17 Sep 2015)
* [[OSSN/OSSN-0053|OSSN-0053]] - Keystone token disclosure may result in malicious trust creation (23 Sep 2015)
* [[OSSN/OSSN-0052|OSSN-0052]] - Python-swiftclient exposes raw token values in debug logs (17 Sep 2015)
* [[OSSN/OSSN-0049|OSSN-0049]] - Nova ironic driver logs sensitive information while operating in debug mode (7 Jul 2015)
* [[OSSN/OSSN-0048|OSSN-0048]] - Glance method filtering does not work under certain conditions (30 Apr 2015)
* [[OSSN/OSSN-0047|OSSN-0047]] - Keystone does not validate that identity providers match federation mappings (19 Apr 2015)
* [[OSSN/OSSN-0046|OSSN-0046]] - Setting services to debug mode can also set Pecan to debug (11 May 2015)
* [[OSSN/OSSN-0045|OSSN-0045]] - Vulnerable clients allow a TLS protocol downgrade (FREAK) (11 Mar 2015)
* [[OSSN/OSSN-0044|OSSN-0044]] - Older versions of noVNC allow session theft (2 Mar 2015)
* [[OSSN/OSSN-0043|OSSN-0043]] - glibc 'Ghost' vulnerability can allow remote code execution (5 Feb 2015)
* [[OSSN/OSSN-0042|OSSN-0042]] - Keystone token scoping provides no security benefit (17 Dec 2014)
* [[OSSN/OSSN-0041|OSSN-0041]] - Linux ISCSI Admin Utility (tgtadm) does not work with Cinder ('''work in progress''')
* [[OSSN/OSSN-0039|OSSN-0039]] - Configuring OpenStack deployments to prevent POODLE attacks (21 Oct 2014)
* [[OSSN/OSSN-0038|OSSN-0038]] - Suds client subject to cache poisoning by local attacker (17 Dec 2014)
* [[OSSN/OSSN-0037|OSSN-0037]] - Configure Horizon to mitigate BREACH/CRIME attacks (19 Sep 2013)
* [[OSSN/OSSN-0036|OSSN-0036]] - Horizon does not set Secure Attribute in cookies (19 Sep 2013)
* [[OSSN/OSSN-0035|OSSN-0035]] - HTTP Strict Transport Security not enabled on Horizon Dashboard (19 Sep 2013)
* [[OSSN/OSSN-0034|OSSN-0034]] - Restarting memcached loses revoked token list (19 Sep 2013)
* [[OSSN/OSSN-0033|OSSN-0033]] - Some SSL-Enabled connections fail to perform basic certificate checks (19 Sep 2013)
* [[OSSN/OSSN-0032|OSSN-0032]] - Disabling a tenant does not disable a user token (30 Aug 2013)
* [[OSSN/OSSN-0031|OSSN-0031]] - Nova Baremetal exposes previous tenant data (2 Jul 2013)
* [[OSSN/OSSN-0030|OSSN-0030]] - Bash 'shellshock' bug can lead to code injection vulnerability (26 Sep 2014)
* [[OSSN/OSSN-0029|OSSN-0029]] - Neutron firewall rules lack port restrictions when using protocol 'any' (24 Sep 2014)
* [[OSSN/OSSN-0028|OSSN-0028]] - Nova leaks compute host SMBIOS serial number to guests (3 Oct 2014)
* [[OSSN/OSSN-0027|OSSN-0027]] - Neutron ARP cache poisoning vulnerability (16 Sep 2014)
* [[OSSN/OSSN-0026|OSSN-0026]] - Unrestricted write permission to config files can allow code execution (5 Sep 2014)
* [[OSSN/OSSN-0025|OSSN-0025]] - Swift can allow images to be accessed by anyone on the same network when using delay_auth_decision (21 Oct 2014)
* [[OSSN/OSSN-0024|OSSN-0024]] - Sensitive data exposure by logging in python-keystoneclient (25 Sep 2014)
* [[OSSN/OSSN-0023|OSSN-0023]] - Keystone logs auth tokens in URLs at the INFO log level (4 Sep 2014)
* [[OSSN/OSSN-0022|OSSN-0022]] - Nova Networking does not enforce security group rules following a soft reboot of an instance (11 Aug 2014)
* [[OSSN/OSSN-0021|OSSN-0021]] - Users of compromised accounts should verify Keystone trusts (25 July 2014)
* [[OSSN/OSSN-0020|OSSN-0020]] - Disassociating floating IP from a VM does not terminate NAT connections (15 Sep 2014)
* [[OSSN/OSSN-0019|OSSN-0019]] - Cinder SSH Pool will auto-accept SSH host signatures by default (30 Jun 2014)
* [[OSSN/OSSN-0018|OSSN-0018]] - Nova Network configuration allows guest VMs to connect to host services (25 Jun 2014)
* [[OSSN/OSSN-0017|OSSN-0017]] - Session-fixation vulnerability in Horizon when using the default signed cookie sessions (20 Jun 2014)
* [[OSSN/OSSN-0016|OSSN-0016]] - Cinder wipe fails in an insecure manner on Grizzly (3 Jun 2014)
* [[OSSN/OSSN-0015|OSSN-0015]] - Glance allows non-admin users to create public images (31 May 2014)
* [[OSSN/OSSN-0014|OSSN-0014]] - Cinder drivers set insecure file permissions (31 May 2014)
* [[OSSN/OSSN-0013|OSSN-0013]] - Some versions of Glance do not apply property protections as expected (7 May 2014)
* [[OSSN/OSSN-0012|OSSN-0012]] - OpenSSL Heartbleed vulnerability can lead to OpenStack compromise (10 Apr 2014)
* [[OSSN/OSSN-0011|OSSN-0011]] - Heat templates with invalid references allows unintended network access (4 Apr 2014)
* [[OSSN/OSSN-0010|OSSN-0010]] - Sample Keystone v3 policy exposes privilege escalation vulnerability (17 Apr 2014)
* [[OSSN/OSSN-0009|OSSN-0009]] - Potential token revocation abuse via group membership (2 Apr 2014)
* [[OSSN/OSSN-0008|OSSN-0008]] - DoS style attack on noVNC server can lead to service interruption or disruption (9 Mar 2014)
* [[OSSN/OSSN-0007|OSSN-0007]] - Live migration instructions recommend unsecured libvirt remote access (6 Mar 2014)
* [[OSSN/1254619|OSSN-0006]] - Keystone can allow user impersonation when using REMOTE_USER for external authentication (17 Jan 2014)
* [[OSSN/1226078|OSSN-0005]] - Glance allows sharing of images between projects without consumer project approval (11 Dec 2013)
* [[OSSN/1237989|OSSN-0004]] - Authenticated users are able to update passwords without providing their current password (22 Nov 2013)
* [[OSSN/1168252|OSSN-0003]] - Keystone configuration should not be world readable (13 May 2013)
* [[OSSN/1155566|OSSN-0002]] - HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS (23 Apr 2013)
* [[OSSN/1098582|OSSN-0001]] - Selecting LXC as Nova Virtualization Driver can lead to data compromise (15 Mar 2013)

OSSN/OSSN-0078

2017-03-09T11:12:59Z

Lhinds: Created page with "https://bugs.launchpad.net/ossn/+bug/1606495"

https://bugs.launchpad.net/ossn/+bug/1606495