[security] Widespread Timing Vulnerabilities in OpenID implementations

[Nate Lawson]

Phillip Hallam-Baker wrote:
> That would seem to me to point to a more general fix.
> 
> I don't like fixes that depend on the skill and intelligence of the
> implementer. They tend to come unstuck. Fixing this timing bug is
> good, but how many others are there?
> 
> A much easier fix to implement and one that would have general
> applicability against timing attacks would be to insert a delay before
> returning an error condition. This has the additional benefit of
> slowing down the attacker.
> 
> 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).

No.

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

In order to help people skip the standard progression of awareness to
timing attacks, we wrote this post 6 months ago. It might be worth
reading before the next suggestion I expect (random delays):

http://rdist.root.org/2010/01/07/timing-independent-array-comparison/

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