[security] Widespread Timing Vulnerabilities in OpenID implementations

[Nate Lawson]

James A. Donald wrote:
>>> I record the time I receive a packet as a matter of course. It would
>>> not be difficult to write some code that ensures that the time take to
>>> return an error is quantized at a pretty coarse level (10ms or so).
> 
> On 2010-07-17 4:16 AM, Nate Lawson wrote:
>> The attack then evolves to:
>>
>> 1. Ping server with correct login to known account, timing for expected
>> RTT on success.
>> 2. Perform timing attack on forged cookie:
>> a. Each guess, wait predicted RTT+epsilon. If server has not responded
>> by deadline, issue TCP RST and connect again.
>> b. Parallelize this to guess across multiple sessions
> 
> This does not work.
> 
> The essence of a timing attack is that instead of the response telling
> the attacker whether his guess was right or wrong, it tells the attacker
> how wrong his guess was, so he can zero in in small steps.  If the delay
> on an error response is coarsely quantized, then it does *not* tell the
> attacker how wrong his guess was.

Sorry, the above part was only appropriate to password guessing (online
dictionary attack) and not timing attacks. You're correct.

However, it does parallelize well. Because of the intentional stateless
nature of these protocols, you can't prevent that. The attacker doesn't
have to keep their own state for all these sessions. He can encode it in
the request itself a la SYN cookies. So this approach would not slow
down an attacker.

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