[security] Widespread Timing Vulnerabilities in OpenID implementations

Phillip Hallam-Baker hallam at gmail.com
Sat Jul 17 21:01:14 UTC 2010


These protocols are not really stateless. If you implement them in a
stateless manner you are going to have lots of security
vulnerabilities.

If you want the protocol to be genuinely stateless you need to make
more demands of the client and have a nonce challenge involved in the
verification process. The big requirement is to make it possible for
any host to respond to a particular client request. Maintaining state
across individual server requests is a little trickier than slap it
and see programing, but not that hard.


My bigger point though is that there are two approaches to security
design. One is 'don't make mistakes', which is what most white hats
think should be the answer. But as we know, even though the best
programmers never have buffer overrun bugs any code base of any
appreciable size written in standard C or C++ will have them.

The other approach to security is to eliminate the possibility of
making the type of mistake that leads to error. Java and C# do not
have buffer over-run errors (except in their C libraries!). You can
write code in C with a real memory manager and checked string handling
routines. My personal implementation of strcmp is

int strcmp (char*a, *b) {
   CONSOLE ("You idiot");
   halt(0);
   }

If you want to be serious about timing errors then look at the timing
of all your responses and make sure that you are not giving any.


On Sat, Jul 17, 2010 at 11:39 AM, Nate Lawson <nate at rootlabs.com> wrote:
> 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
>
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>



-- 
Website: http://hallambaker.com/


More information about the security mailing list