[security] Widespread Timing Vulnerabilities in OpenID implementations

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


That's understandable. I can pass on the word to some of the PHP  
implementations, at least, and check on the PECL C extension for PHP. It has 
already been resolved (or  marked for resolution at next minor version) for a 
few months in  anything I'm personally involved in. PHP must have anything over 
20 reasonably commonly available OpenID/OAuth libs including C extensions.

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

True, that was what I benchmarked last November or so when I was researching 
this topic and ported the suggested function to PHP. It's implicit in 
benchmarking to compare like with like. As I recall, the only concern at the 
time with the replacement function was that it leaked length information 
(somewhat leaky for variable length passwords or phrases rather than the 
documented fixed length of something derived from HMAC). No idea if anyone else 
in PHP has been talking about timing attacks of this nature though - any new 
data from the Blackhat conf can only help raise awareness and get over 
developers' initial disbelief - "internet jitter" remains a compelling argument 
with those I've mentioned timing attacks to.

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: Breno de Medeiros <breno at google.com>
Cc: Pádraic Brady <padraic.brady at yahoo.com>; Andrew Arnott 
<andrewarnott at gmail.com>; openid-security <openid-security at lists.openid.net>
Sent: Fri, July 16, 2010 6:45:37 PM
Subject: Re: [security] Widespread Timing Vulnerabilities in OpenID   
implementations

Breno de Medeiros 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.

Yes, that's what I was checking on.

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

No, there are too many. We've also notified all OAuth, various web
frameworks, and others not yet public. There are at least 30 known
affected libraries and up to double that unknown. We can't review
everything.

-- 
Nate Lawson
Root Labs :: www.rootlabs.com
+1 (510) 595-9505 / (415) 305-5638 mobile
Solving embedded security, kernel and crypto challenges
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20100716/159b503c/attachment-0001.html>


More information about the security mailing list