- OpenStack-announce - lists.openstack.org

[OSSA 2014-024] Use of non-constant time comparison operation (CVE-2014-3517)
by Grant Murphy 17 Jul '14

17 Jul '14

OpenStack Security Advisory: 2014-024 CVE: CVE-2014-3517 Date: July 17, 2014 Title: Use of non-constant time comparison operation Reporter: Alex Gaynor (Rackspace) Products: Nova Versions: Up to 2013.2.3, and 2014.1 to 2014.1.1 Alex Gaynor from Rackspace reported a timing attack vulnerability in Nova. By analyzing response times to requests for instance metadata, an attacker may be able to guess a valid instance ID signature. This could allow access to important configuration details of another instance. Only setups configured to proxy metadata requests via Neutron are affected. Juno (development branch) fix: https://review.openstack.org/107396 Icehouse https://review.openstack.org/107397 Havana https://review.openstack.org/107398 Notes: This fix will be included in the Juno-2 development milestone and in future 2013.2.4 and 2014.1.2 releases References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3517 https://launchpad.net/bugs/1325128 -- Grant Murphy OpenStack Vulnerability Management Team

1 0

OpenStack Community Weekly Newsletter (July 4 - 11)
by Stefano Maffulli 12 Jul '14

12 Jul '14

1 0

[OSSA 2014-023] Multiple XSS vulnerabilities in Horizon (CVE-2014-3473, CVE-2014-3474, and CVE-2014-3475)
by Tristan Cacqueray 08 Jul '14

08 Jul '14

OpenStack Security Advisory: 2014-023 CVE: CVE-2014-3473, CVE-2014-3474, and CVE-2014-3475 Date: July 08, 2014 Title: Multiple XSS vulnerabilities in Horizon Reporter: Jason Hullinger (HP) - CVE-2014-3473 Craig Lorentzen (Cisco) - CVE-2014-3474 Michael Xin (Rackspace) - CVE-2014-3475 Products: Horizon Versions: up to 2013.2.3, and 2014.1 versions up to 2014.1.1 Description: Jason Hullinger from Hewlett Packard, Craig Lorentzen from Cisco and Michael Xin from Rackspace reported 3 cross-site scripting (XSS) vulnerabilities in Horizon. A malicious Orchestration template owner or catalog may conduct an XSS attack once a corrupted template is used in the Orchestration/Stack section of Horizon. A malicious Horizon user may store an XSS attack by creating a network with a corrupted name. A malicious Horizon administrator may store an XSS attack by creating a user with a corrupted email address. Once executed in a legitimate context these attacks may result in potential asset stealing (horizon user/admin access credentials, VMs/Network configuration/management, tenants' confidential information, etc.). All Horizon setups are affected. Juno (development branch) fix: https://review.openstack.org/105476 Icehouse fix: https://review.openstack.org/105477 Havana fix: https://review.openstack.org/105478 Notes: This fix will be included in the Juno-2 development milestone and in future 2013.2.4 and 2014.1.2 releases. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3473 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3474 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3475 https://launchpad.net/bugs/1308727 https://launchpad.net/bugs/1320235 https://launchpad.net/bugs/1322197 -- Tristan Cacqueray OpenStack Vulnerability Management Team

1 0

Swift 2.0.0 has been released and includes support for storage policies
by John Dickinson 08 Jul '14

08 Jul '14

I'm happy to announce that Swift 2.0.0 has been officially released! You can get the tarball at http://tarballs.openstack.org/swift/swift-2.0.0.tar.gz. This release is a huge milestone in the history of Swift. This release includes storage policies, a set of features I've often said is the most important thing to happen to Swift since it was open-sourced. What are storage policies, and why are they so significant? Storage policies allow you to set up your cluster to exactly match your use case. From a technical perspective, storage policies allow you to have more than one object ring in your cluster. Practically, this means that you can can do some very important things. First, given the global set of hardware for your Swift deployment, you can choose which set of hardware your data is stored on. For example, this could be performance-based, like with flash vs spinning drives, or geography-based, like Europe vs North America. Second, once you've chosen the subset of hardware for your data, storage policies allow you to choose how the data is stored across that set of hardware. You can choose the replication factor independently for each policy. For example, you can have a "reduced redundancy tier", a "3x replication tier", and also a tier with a replica in every geographic region in the world. Combined with the ability to choose the set of hardware, this gives you a huge amount of control over how your data is stored. Looking forward, storage policies is the foundation upon we are building support for non-replicated storage. With this release, we are able to focus on building support for an erasure code storage policy, thus giving the ability to more efficiently store large data sets. For more information, start with the developer docs for storage policies at http://swift.openstack.org/overview_policies.html. I gave a talk on storage policies at the Atlanta summit last April. https://www.youtube.com/watch?v=mLC1qasklQo The full changelog for this release is at https://github.com/openstack/swift/blob/master/CHANGELOG. --John

1 0

OpenStack Community Weekly Newsletter (June 27 – July 4)
by Stefano Maffulli 04 Jul '14

04 Jul '14

1 0

[OSSA 2014-022] Keystone V2 trusts privilege escalation through user supplied project id (CVE-2014-3520)
by Tristan Cacqueray 02 Jul '14

02 Jul '14

OpenStack Security Advisory: 2014-022 CVE: CVE-2014-3520 Date: July 02, 2014 Title: Keystone V2 trusts privilege escalation through user supplied project id Reporter: Jamie Lennox (Red Hat) Products: Keystone Versions: up to 2013.2.3, and 2014.1 to 2014.1.1 Description: Jamie Lennox from Red Hat reported a vulnerability in Keystone trusts. By using an out of scope project id, a trustee may gain unauthorized access if the trustor has the required roles in the requested project id. All Keystone deployments configured to enable trusts and V2 API are affected. Juno (development branch) fix: https://review.openstack.org/104216 Icehouse fix: https://review.openstack.org/104217 Havana fix: https://review.openstack.org/104218 Notes: This fix will be included in the Juno-2 development milestone and in future 2013.2.4 and 2014.1.2 releases. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3520 https://launchpad.net/bugs/1331912 --· Tristan Cacqueray OpenStack Vulnerability Management Team

1 0

OpenStack Community Weekly Newsletter (June 20 – 27)
by Stefano Maffulli 28 Jun '14

28 Jun '14

1 0

python-heatclient 0.2.9 released
by Steve Baker 27 Jun '14

27 Jun '14

The heat development community would like to announce the release of python-heatclient version 0.2.9. python-heatclient is a client library for Heat built on the Heat orchestration API. It provides a Python API (the heatclient module) and a command-line tool (heat). This release can be installed from the following locations: http://tarballs.openstack.org/python-heatclient <http://tarballs.openstack.org/python-heatclient> https://pypi.python.org/pypi/python-heatclient <https://pypi.python.org/pypi/python-heatclient> Changes in this release: https://launchpad.net/python-heatclient/+milestone/v0.2.9 <https://launchpad.net/python-heatclient/+milestone/v0.2.5>

1 1

[OSSA 2014-021] User token leak to message queue in pyCADF notifier middleware (CVE-2014-4615)
by Tristan Cacqueray 25 Jun '14

25 Jun '14

OpenStack Security Advisory: 2014-021 CVE: CVE-2014-4615 Date: June 25, 2014 Title: User token leak to message queue in pyCADF notifier middleware Reporter: Zhi Kun Liu (IBM) Products: Neutron (2014.1 versions up to 2014.1.1) Ceilometer (2013.2 versions up to 2013.2.3, 2014.1 versions up to 2014.1.1) pyCADF library (all versions up to 0.5.0) Description: Zhi Kun Liu from IBM reported a vulnerability in the notifier middleware available in the PyCADF library and formerly copied into Neutron and Ceilometer code. An attacker with read access to the message queue may obtain authentication tokens used in REST requests (X_AUTH_TOKEN) that goes through the notifier middleware. All services using the notifier middleware configured after the auth_token middleware pipeline are impacted. pyCADF fix (included in 0.5.1 release): https://review.openstack.org/94878 (pyCADF) Juno (development branch) fix: https://review.openstack.org/94891 (Neutron) Icehouse fix: https://review.openstack.org/101097 (Neutron) https://review.openstack.org/96944 (Ceilometer) Havana fix: https://review.openstack.org/101799 (Ceilometer) Notes: Ceilometer Juno (master) branch is not affected. Those fixes will be included in the Juno-2 development milestone and in future 2013.2.4 and 2014.1.2 releases. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4615 https://launchpad.net/bugs/1321080 -- Tristan Cacqueray OpenStack Vulnerability Management Team

1 0

OpenStack Community Weekly Newsletter (June 13 - 20)
by Stefano Maffulli 21 Jun '14

21 Jun '14

1 0