[security] Widespread Timing Vulnerabilities in OpenID implementations

Nate Lawson nate at rootlabs.com
Wed Jul 14 16:19:29 UTC 2010


John Bradley wrote:
> On 2010-07-14, at 1:53 AM, Nate Lawson wrote:
>> Let's not let this discussion cloud what we are announcing: all OpenID
>> libraries we reviewed leak timing information about the correct HMAC.
>> This is a security bug and should be fixed, just like it has been in
>> Ruby on Rails, Java JCE, Google Keyczar, etc.
>>
> Agreed

Great, hopefully maintainers can figure out the fix. We're happy to
review patches if they have them.

>> I fail to see how OpenID specification language about the RP checking
>> nonces prevents the attack as you suggest it does. The nonce is there to
>> prevent replays of valid assertions that an attacker sniffed between the
>> RP and OP.
>>
> The nonce limits the time that the assertion is valid.   Given that this attack relies on the assertion being replayed with different signatures it limits the time an attacker has to perform the compromise.

This brings up a problem in the OpenID spec: confusion between "nonce"
and "timestamp", two very different protocol features. Really, the
"response_nonce" field should be named "response_timestamp_and_nonce"
except for brevity.

The timestamp portion can limit the time an assertion is valid if an RP
chooses to do so (spec says "MAY", ICAM says "RECOMMENDED"). The nonce
portion prevents replay by extending the resolution of the timestamp, so
that even two parallel responses have a unique value (spec says
"SHOULD", ICAM says "MUST").

>> If you're depending on order of operations, there is no specification
>> requirement that the RP validate nonces before the HMAC signature is
>> verified. An implementation can return a "signature failed" error for a
>> message with a fixed nonce multiple times, enabling this timing attack.
>>
> True,  I need to look at if we should be more specific about that in the ICAM profile.
> 
> Checking the nonce/timestamp before the signature limits the effectiveness of this and perhaps future attacks against HMAC.

Yes, the nonce only prevents replay of operations AFTER the point at
which it is checked. All operations before it is checked are subject to
replay.

>> As you can see, the vague language in the first part ("When the RP
>> checks the signature...") means an implementation can check the nonce
>> either before or after the signature. If it does so after, it is
>> exploitable. The attacker can choose a timestamp a few days in the
>> future, perform the timing attack, and then save the correct
>> Authentication Response until it becomes valid.
>>
>> We reviewed the implementations mentioned in Taylor's initial mail
>> before contacting this list. The JOpenID implementation does not
>> validate nonces at all ("TODO"). The Python and Ruby implementations
>> (http://www.janrain.com/openid-enabled) validate nonces, but do it
>> *after* checking the signature.
> 
> As I said the quality of  openID libraries varies widely.  I have found more than one that completely failed to check the signature.
> As well as OP's that did not sign all of the required elements.

I don't think this can be blamed on the OpenID libraries we pointed out.
Neither the specification nor ICAM require an order here, so
implementations are free to do it in whatever order they want.

> The ICAM profile of openID 2.0 is available at:
> http://idmanagement.gov/drilldown.cfm?action=openID_openGOV
> 
> We will look at tightening up the language for nonce checking, as well as guidance on the timing attack.
> 
> Likely that is covered in FIPS guidelines, but it is unlikely that openID authors have read all of those guidelines.

That would be great. Which FIPS are you referring to, 140-2?

>> Side channel attacks are tricky business. We've spent most of our
>> careers working with them, in areas other than web security. Given how
>> simple the fix is, we think it is better not to rely on this timing
>> attack accidentally not being exploitable in a given implementation.
>>
>> Additionally, we think it would be good to provide additional
>> specification guidance to implementers on the need to avoid leaking info
>> about the HMAC and to validate the nonce before the signature.
>>
> Agreed,  However socializing this with the library maintainers will be much faster than trying to get the openID 2.0 spec updated.

Yes, that is what we were trying to do here. However, it would be good
if the spec was updated eventually as well. OpenID has a pretty strong
separation between specification and numerous implementations, so we
want to make sure future implementations that appear benefit from this
guidance.

-- 
Nate Lawson
Root Labs :: www.rootlabs.com
+1 (510) 595-9505 / (415) 305-5638 mobile
Solving embedded security, kernel and crypto challenges



More information about the security mailing list