[security] Widespread Timing Vulnerabilities in OpenID implementations

[Nate Lawson]

James A. Donald wrote:
> On 2010-07-14 4:12 PM, Eric Norman wrote:
>> If I understand the alleged attack correctly, it depends on the timing
>> difference if a standard
>> byte sequence comparison is "optimized" by exiting as soon as two
>> bytes differ.
>>
>> Has code been written that actually demonstrates that this can be
>> effective?  That is, has code
>> been written to demonstrate that the time to execute, for instance,
>> about two instructions
>> between failure of the byte comparison at the first byte and failure
>> at the second byte can
>> actually be detected over a network?
> 
> While timing leaks need to be fixed as a matter of policy, perhaps by
> starting the compare at a random point within the token, this is not a
> real leak, since the timing difference is nanoseconds, and routing
> jitter is milliseconds

Starting the compare at a random point is much more difficult and
error-prone than implementing a constant-time compare function. Please
see Taylor's original note, which included such a constant-time function.

You are incorrect about both the timing delta and unfiltered jitter. The
timing delta is much more than nanoseconds in languages such as Java and
Ruby. We will give the hard numbers at our talk.

For jitter, please see my reply to Eric this morning giving old research
results of 20 microseconds unfiltered jitter on the WAN and 100
nanoseconds on the LAN. You can measure deltas well below the round-trip
time with proper filtering.

The whole point of our talk, really, is to clear up misconceptions such
as these with experimental results.

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