Ceilometer should use a constant time comparison function when comparing signatures
Bug #1332390 reported by
Grant Murphy
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Fix Released
|
High
|
Mehdi Abaakouk | ||
OpenStack Security Advisory |
Invalid
|
Undecided
|
Unassigned |
Bug Description
This comparison should really use a constant time comparison operation.
https:/
There are examples of how to do this in other places in the openstack code base.
For more information on this issue consider reading this -
http://
Marked as security issue, may not an exploitable scenario. Request input from ceilometer security team.
Suggest fix for hardening purposes in any case.
Changed in ossa: | |
status: | New → Incomplete |
Changed in ceilometer: | |
assignee: | nobody → Mehdi Abaakouk (sileht) |
information type: | Private Security → Public |
Changed in ossa: | |
status: | Incomplete → Invalid |
Changed in ceilometer: | |
assignee: | Mehdi Abaakouk (sileht) → Grant Murphy (gmurphy) |
Changed in ceilometer: | |
milestone: | none → juno-2 |
importance: | Undecided → High |
Changed in ceilometer: | |
status: | Fix Committed → Fix Released |
Changed in ceilometer: | |
milestone: | juno-2 → 2014.2 |
To post a comment you must log in.
Relevant discussion on IRC:
[15:29] <eglynn> so seems to me that this exploit depends on the message signature validation occuring inline, synchronously within a user-callable API
[15:29] <gmurphy> sure.
[15:29] <eglynn> otherwise the timing differences are indetectable
[15:30] <eglynn> so the collector agent in ceilo that verifies metering message signatures is not on the inline dispatch patch of an API call
[15:30] <eglynn> i.e. it act asynchronously in consuming these metering messages
[15:30] <eglynn> makes sense?
[15:31] <gmurphy> yeah. these kinds of things are usually pretty unlikely. i didn't think this would necessarily an exploitable scenario. thanks for your help debunking that one.
[15:32] <eglynn> cool, thanks for bringing up on our radar in any case
[15:32] <eglynn> happy for this to closed as NOTABUG?
[15:32] <gmurphy> np. found it because there was another case that was a little more dangerous
[15:32] <eglynn> another case in ceilometer, or in another openstack service?
[15:33] <gmurphy> i guess. maybe i'll submit a constant time compare patch as hardening.
[15:33] <gmurphy> not in ceilometer.
[15:33] <gmurphy> so was just checking all openstack for similar issues
[15:33] <gmurphy> just to be thorough.
[15:33] <gmurphy> anyway. thanks again for your help.
[15:33] <eglynn> thoroughness is good, thanks for that!
[15:34] <eglynn> so if you're planning to submit a patch for hardening, we can leave the bug open
[15:34] <eglynn> ... but declassify as a vulnerability?
[15:34] <gmurphy> yeah. we should probably open it and not as a security bug.
[15:34] <gmurphy> assign it to me
[15:34] <eglynn> sounds good, will do
[15:35] <gmurphy> thanks
[15:35] <eglynn> and thank *you* sir for your attention to detail on this!