Timing vulnerabilities throughout openstack
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Russell Bryant | ||
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Russell Bryant | ||
OpenStack Object Storage (swift) |
Fix Released
|
Medium
|
Russell Bryant |
Bug Description
I filed this bug against keystone because it is the most practically exploitable. Everywhere else that uses a tokenized API or signatures should be audited.
For those who haven't encountered them before, the timing attacks I'm reporting here allow an attacker to deduce the correct value for authentication tokens in much less than brute force time when those tokens are validated with a simple equality comparison.
A quick and easy introduction:
http://
Some practical recent research:
http://
(the actual presentation)
http://
Keystone uses passlib to hash and compare user passwords. This is good, because it includes an opaque password validity check which is hardened against timing attacks.
Unfortunately, most of the other token validation routines in openstack use equality comparisons for this, rather than a constant time compare function like this one:
https:/
Here are a few examples of brokenness. There are probably quite a few more, I haven't done a full audit.
https:/
https:/
https:/
https:/
https:/
https:/
This one is more subtle - given a valid token, it allows an attacker to deduce the correct username
https:/
While these vulnerabilities may be difficult to exploit over the general internet, an openstack installation can expect an attack from a compromised node, which may be as far away as gigabit switched ethernet, or as close as a vm container on the same physical host. In the latter case, timing attacks even against string comparisons are eminently practical.
Timing attacks are one of the topics I'll be discussing at Pycon on March 9. It would be nice to have these fixed before then.
description: | updated |
description: | updated |
visibility: | private → public |
Changed in keystone: | |
assignee: | nobody → Russell Bryant (russellb) |
milestone: | none → essex-rc1 |
Changed in nova: | |
milestone: | none → essex-4 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
status: | Confirmed → In Progress |
Changed in swift: | |
milestone: | none → 1.4.7 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | essex-rc1 → 2012.1 |
Changed in nova: | |
milestone: | essex-4 → 2012.1 |
Thanks for the report. I have marked this issue as confirmed and subscribed the project leads to the bug for the projects you reported this against.
I can write patches for the instances pointed out here, but will probably need some help with the audit to make sure all the appropriate places get patched.