| 2012-02-28 14:41:55 |
Paul McMillan |
bug |
|
|
added bug |
| 2012-02-28 14:42:25 |
Paul McMillan |
bug task added |
|
nova |
|
| 2012-02-28 14:42:44 |
Paul McMillan |
bug task added |
|
swift |
|
| 2012-02-28 15:23:42 |
Russell Bryant |
keystone: status |
New |
Confirmed |
|
| 2012-02-28 15:23:58 |
Russell Bryant |
nova: status |
New |
Confirmed |
|
| 2012-02-28 15:24:01 |
Russell Bryant |
swift: status |
New |
Confirmed |
|
| 2012-02-28 15:24:14 |
Russell Bryant |
bug |
|
|
added subscriber Vish Ishaya |
| 2012-02-28 15:24:26 |
Russell Bryant |
bug |
|
|
added subscriber Ziad Sawalha |
| 2012-02-28 15:24:37 |
Russell Bryant |
bug |
|
|
added subscriber John Dickinson |
| 2012-02-28 16:44:04 |
Russell Bryant |
attachment added |
|
nova-timing-attacks.rev1.txt https://bugs.launchpad.net/keystone/+bug/942644/+attachment/2791259/+files/nova-timing-attacks.rev1.txt |
|
| 2012-02-28 16:44:29 |
Russell Bryant |
attachment added |
|
swift-timing-attacks.rev1.txt https://bugs.launchpad.net/keystone/+bug/942644/+attachment/2791260/+files/swift-timing-attacks.rev1.txt |
|
| 2012-02-28 16:44:59 |
Russell Bryant |
attachment added |
|
keystone-timing-attacks.rev1.txt https://bugs.launchpad.net/keystone/+bug/942644/+attachment/2791261/+files/keystone-timing-attacks.rev1.txt |
|
| 2012-02-28 18:58:28 |
Paul McMillan |
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://codahale.com/a-lesson-in-timing-attacks/
Some practical recent research:
http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/
(the actual presentation)
http://www.youtube.com/results?search_query=nate+lawson+timing
Keystone uses passlib do 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://code.djangoproject.com/browser/django/trunk/django/utils/crypto.py#L78
Here are a few examples of brokenness. There are probably quite a few more, I haven't done a full audit.
https://github.com/openstack/keystone/blob/master/keystone/contrib/s3/core.py#L50
https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/core.py#L108
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L331,
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L343
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L346
https://github.com/openstack/swift/blob/master/swift/common/middleware/formpost.py#L445
This one is more subtle - given a valid token, it allows an attacker to deduce the correct username
https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L245
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. |
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://codahale.com/a-lesson-in-timing-attacks/
Some practical recent research:
http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/
(the actual presentation)
http://www.youtube.com/results?search_query=nate+lawson+timing
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://code.djangoproject.com/browser/django/trunk/django/utils/crypto.py#L78
Here are a few examples of brokenness. There are probably quite a few more, I haven't done a full audit.
https://github.com/openstack/keystone/blob/master/keystone/contrib/s3/core.py#L50
https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/core.py#L108
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L331,
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L343
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L346
https://github.com/openstack/swift/blob/master/swift/common/middleware/formpost.py#L445
This one is more subtle - given a valid token, it allows an attacker to deduce the correct username
https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L245
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. |
|
| 2012-02-28 19:49:38 |
Paul McMillan |
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://codahale.com/a-lesson-in-timing-attacks/
Some practical recent research:
http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/
(the actual presentation)
http://www.youtube.com/results?search_query=nate+lawson+timing
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://code.djangoproject.com/browser/django/trunk/django/utils/crypto.py#L78
Here are a few examples of brokenness. There are probably quite a few more, I haven't done a full audit.
https://github.com/openstack/keystone/blob/master/keystone/contrib/s3/core.py#L50
https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/core.py#L108
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L331,
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L343
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L346
https://github.com/openstack/swift/blob/master/swift/common/middleware/formpost.py#L445
This one is more subtle - given a valid token, it allows an attacker to deduce the correct username
https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L245
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. |
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://codahale.com/a-lesson-in-timing-attacks/
Some practical recent research:
http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/
(the actual presentation)
http://www.youtube.com/results?search_query=nate+lawson+timing
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://code.djangoproject.com/browser/django/trunk/django/utils/crypto.py#L78
Here are a few examples of brokenness. There are probably quite a few more, I haven't done a full audit.
https://github.com/openstack/keystone/blob/master/keystone/contrib/s3/core.py#L50
https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/core.py#L108
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L331,
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L343
https://github.com/openstack/nova/blob/master/nova/auth/manager.py#L352
https://github.com/openstack/swift/blob/master/swift/common/middleware/formpost.py#L445
This one is more subtle - given a valid token, it allows an attacker to deduce the correct username
https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L245
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. |
|
| 2012-02-28 19:50:35 |
Russell Bryant |
visibility |
private |
public |
|
| 2012-02-28 19:57:03 |
OpenStack Infra |
nova: status |
Confirmed |
In Progress |
|
| 2012-02-28 19:57:03 |
OpenStack Infra |
nova: assignee |
|
Russell Bryant (russellb) |
|
| 2012-02-28 19:57:20 |
OpenStack Infra |
swift: status |
Confirmed |
In Progress |
|
| 2012-02-28 19:57:20 |
OpenStack Infra |
swift: assignee |
|
Russell Bryant (russellb) |
|
| 2012-02-28 20:27:29 |
OpenStack Infra |
nova: status |
In Progress |
Fix Committed |
|
| 2012-02-28 23:31:58 |
Joseph Heck |
keystone: assignee |
|
Russell Bryant (russellb) |
|
| 2012-02-28 23:32:10 |
Joseph Heck |
keystone: milestone |
|
essex-rc1 |
|
| 2012-02-29 03:35:33 |
OpenStack Infra |
swift: status |
In Progress |
Fix Committed |
|
| 2012-02-29 10:37:30 |
Thierry Carrez |
nova: status |
Fix Committed |
Fix Released |
|
| 2012-02-29 10:37:30 |
Thierry Carrez |
nova: milestone |
|
essex-4 |
|
| 2012-02-29 15:18:33 |
OpenStack Infra |
keystone: status |
Confirmed |
In Progress |
|
| 2012-02-29 18:29:05 |
OpenStack Infra |
keystone: status |
In Progress |
Fix Committed |
|
| 2012-03-01 15:25:52 |
Thierry Carrez |
keystone: importance |
Undecided |
Medium |
|
| 2012-03-01 15:25:55 |
Thierry Carrez |
nova: importance |
Undecided |
Medium |
|
| 2012-03-01 15:26:01 |
Thierry Carrez |
swift: importance |
Undecided |
Medium |
|
| 2012-03-07 12:32:17 |
Thierry Carrez |
swift: status |
Fix Committed |
Fix Released |
|
| 2012-03-07 12:32:17 |
Thierry Carrez |
swift: milestone |
|
1.4.7 |
|
| 2012-03-23 20:53:29 |
Thierry Carrez |
keystone: status |
Fix Committed |
Fix Released |
|
| 2012-04-05 08:33:58 |
Thierry Carrez |
keystone: milestone |
essex-rc1 |
2012.1 |
|
| 2012-04-05 10:16:24 |
Thierry Carrez |
nova: milestone |
essex-4 |
2012.1 |
|
