[security] Widespread Timing Vulnerabilities in OpenID implementations

Breno de Medeiros breno at google.com
Fri Jul 16 16:41:41 UTC 2010


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)


More information about the security mailing list