[security] Widespread Timing Vulnerabilities in OpenID implementations

Bob Wyman bob at wyman.us
Fri Jul 16 18:10:54 UTC 2010


On Fri, Jul 16, 2010 at 2:02 PM, Phillip Hallam-Baker <hallam at gmail.com>
 wrote:
> insert a delay before returning an error condition.
> This has the additional benefit of
> slowing down the attacker.

+1

bob wyman

On Fri, Jul 16, 2010 at 2:02 PM, Phillip Hallam-Baker <hallam at gmail.com>wrote:

> 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/
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20100716/22b4d17d/attachment.html>


More information about the security mailing list