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: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | 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: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-02 09:24:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 957485, 958287, 961733, 961736 | ||
| Bug Blocks: | 958289 | ||
References: http://www.openwall.com/lists/oss-security/2013/05/09/2 https://bugs.launchpad.net/nova/+bug/1174608 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2030 Upstream patches: https://review.openstack.org/#/c/28568/ (Havana branch) https://review.openstack.org/#/c/28569/ (Grizzly branch) https://review.openstack.org/#/c/28570/ (Folsom branch) Created openstack-nova tracking bugs for this issue Affects: fedora-all [bug 961733] Affects: epel-6 [bug 961736] 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. 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 The fix for this issue is already included in the current havana and grizzly RDO packages. |
Originally reported by Grant Murphy (gmurphy): 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*