[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