[security] Widespread Timing Vulnerabilities in OpenID implementations

Pádraic Brady padraic.brady at yahoo.com
Fri Jul 16 18:17:45 UTC 2010


$10 says it would become unstuck anyway ;). Implementors/Developers  already 
need intelligence and skill for stacks of other security issues -  this one is 
simpler by far to fix than most.

A delay based fix seems a bit overly specific/complex. Would you not  have to 
time positive conditions across a wide variety of systems and  environments on 
an individual basis in order to apply an appropriate  delay to the error 
condition? I don't see many higher level languages,  at least, heading down that 
road.

Paddy
 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Phillip Hallam-Baker <hallam at gmail.com>
To: Breno de Medeiros <breno at google.com>
Cc: Pádraic Brady <padraic.brady at yahoo.com>; openid-security 
<openid-security at lists.openid.net>
Sent: Fri, July 16, 2010 7:02:18 PM
Subject: Re: [security] Widespread Timing Vulnerabilities in OpenID  
implementations

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).


On Fri, Jul 16, 2010 at 12:41 PM, Breno de Medeiros <breno at google.com> wrote:
> On Fri, Jul 16, 2010 at 08:02, Pádraic Brady <padraic.brady at yahoo.com> wrote:
>> I can only speak for PHP, but the function is also multiples slower than a
>> native comparison from when I was implementing it last year. Not all that
>> surprising given PHP is also built on C (to the point it practically copies
>> functions) so it should resolve similarly.
>
> The only fair comparison here is when the two inputs are equal.
> Lengthening the time of computation when the inputs are different is
> the goal of this fix.
>
>>
>> Just on implementations - have you notified these directly? Not all of them
>> may be paying attention to this list since it's not necessarily
>> implementation specific.
>>
>> Paddy
>>
>> Pádraic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> Zend Framework Community Review Team
>>
>>
>> ________________________________
>> From: Nate Lawson <nate at rootlabs.com>
>> To: Andrew Arnott <andrewarnott at gmail.com>
>> Cc: openid-security <openid-security at lists.openid.net>
>> Sent: Fri, July 16, 2010 12:20:36 AM
>> Subject: Re: [security] Widespread Timing Vulnerabilities in OpenID
>> implementations
>>
>> Andrew Arnott wrote:
>>> These six lines of code turn out to be ~*100 times slower* than the
>>> built-in
>>> .NET String.Equals function.  I don't know why there is such a perf
>>> difference, but apparently .NET has some serious string equality check
>>> optimizations in their native code.  Has anyone else compared the
>>> performance of their language's native string equality check function and
>>> this hand-written alternative?
>>
>> We're doing that as part of our talk. Did you compare 100% correct
>> strings or were they different? Obviously, a compare that terminates
>> early will be faster for non-matching input.
>>
>> When you say 100x slower, what are your actual numbers in terms of
>> nanoseconds per byte for each version?
>>
>> In Python, a string compare with == devolves to a call to C memcmp(). I
>> suspect .NET does the same thing. For Java and Ruby, it doesn't and so
>> the routine Taylor posted is nearly identical in performance to the
>> naive compare.
>>
>> I'm sure the secret_cmp() function could be subject to some
>> language-specific optimizations for non-native environments. It's worth
>> looking into.
>>
>> --
>> 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
>>
>> _______________________________________________
>> security mailing list
>> security at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20100716/1cab34f6/attachment-0001.html>


More information about the security mailing list