This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 958285 - (CVE-2013-2030) CVE-2013-2030 OpenStack nova: insecure directory creation for signing
CVE-2013-2030 OpenStack nova: insecure directory creation for signing
Status: CLOSED CURRENTRELEASE
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All All
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130509,reported=2...
: Security
Depends On: 957485 958287 961733 961736
Blocks: 958289
  Show dependency treegraph
 
Reported: 2013-04-30 16:11 EDT by Kurt Seifried
Modified: 2016-04-26 19:18 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-02 05:24:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Gentoo 469272 None None None Never

  None (edit)
Description Kurt Seifried 2013-04-30 16:11:40 EDT
Originally reported by Grant Murphy (gmurphy@redhat.com):

The signing directory is used to store the signing certificates
and the default location for this directory is:

    signing_dir = /tmp/keystone-signing-nova

In the file:

   keystone/middleware/auth_token.py

During the initialization of the AuthMiddleware the following operations are made for the signing directory:

    IF the directory exists but cannot be written to a configuration error is raised.
    ELSE IF the directory doesn't exist, create it.
    NEXT chmod permisions(stat.S_IRWXU) to the signing_directory

AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory.

This means that if an attacker populated the /tmp/keystone-signing-nova
with the appropriate files for signautre verification they could potentially
issue forged tokens which would be validated by the middleware. As:
    - The directory location deterministic. (default for glance, nova)
    - *If the directory already exists it is reused*
Comment 3 Jan Lieskovsky 2013-05-10 06:57:06 EDT
Created openstack-nova tracking bugs for this issue

Affects: fedora-all [bug 961733]
Affects: epel-6 [bug 961736]
Comment 4 Fedora Update System 2013-05-21 21:29:01 EDT
openstack-keystone-2012.2.4-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Kurt Seifried 2013-05-25 03:52:18 EDT
This was fixed upstream:

http://lists.openstack.org/pipermail/openstack-announce/2013-May/000098.html

OpenStack Security Advisory: 2013-010
CVE: CVE-2013-2030
Date: May 9, 2013
Title: Nova uses insecure keystone middleware tmpdir by default
Reporter: Grant Murphy (Red Hat), Anton Lundin
Products: Nova
Affects: Folsom, Grizzly

Description:
Grant Murphy from Red Hat and Anton Lundin both independently reported a
vulnerability in Nova's default location for the Keystone middleware
signing directory (signing_dir). By previously setting up a malicious
directory structure, an attacker with local shell access on the Nova
node could potentially issue forged tokens that would be accepted by the
middleware. Only setups that use the default value for signing_dir are
affected. Note that future versions of the Keystone middleware will
issue a warning if an insecure signing directory is used.

Havana (development branch) fix:
https://review.openstack.org/#/c/28568/

Grizzly fix:
https://review.openstack.org/#/c/28569/

Folsom fix:
https://review.openstack.org/#/c/28570/

References:
https://bugs.launchpad.net/nova/+bug/1174608
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2030

- -- 
Thierry Carrez (ttx)
OpenStack Vulnerability Management Team
Comment 6 Xavier Queralt 2013-10-02 05:24:00 EDT
The fix for this issue is already included in the current havana and grizzly RDO packages.

Note You need to log in before you can comment on or make changes to this bug.