Bug 958285 (CVE-2013-2030)

Summary: CVE-2013-2030 OpenStack nova: insecure directory creation for signing
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: abaron, aortega, apevec, ayoung, chrisw, cpelland, dallan, jkt, jlieskov, markmc, ndipanov, rbryant, security-response-team, xqueralt
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard: impact=low,public=20130509,reported=20130428,source=redhat,cvss2=2.1/AV:L/AC:L/Au:N/C:N/I:P/A:N,fedora-all/openstack-nova=affected,epel-6/openstack-nova=affected,openstack-1/openstack-nova=wontfix,openstack-2.1/openstack-nova=affected
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:
Bug Depends On: 957485, 958287, 961733, 961736    
Bug Blocks: 958289    

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.