Re: Security implications of network timing

> only possible with the addition of this data. Can you please elaborate
> to provide specific novel attack vectors that arise as a result of
> providing this new data, so we can analyze them and confirm that they
> are indeed not possible without the data provided by resource timing?

To be clear, I'm talking about timing attacks against server-side
vulnerabilities like string equality comparisons, which allow
attackers to figure out authentication tokens. I'm not talking about
the privacy issue, or the blind SQLi technique of "wait for 10 seconds
if true". A good intro to the issue is here:
http://codahale.com/a-lesson-in-timing-attacks/

The timing data that is currently available is extremely rough. It
includes the lookup time, connection time, and of course the delivery
of content. The content of an attacked resource is usually composed of
multiple packets, and by the time they all arrive and get processed,
they obliterate the signal. With the proposed additions, responseStart
- requestStart provides a good proxy for what we really care about -
how long the request took to compute.

Dedicated attack tools can resolve timing differences down into the
tens of nanoseconds on a LAN. These additions will improve attack
capabilities by (handwaving) several orders of magnitude at least.
This allows exploitation of an entirely different class of
vulnerabilities. Right now, browser-facilitated timing attacks are
impractical except in cases like blind SQLi where your difference is
measured in seconds. With the additions, I can measure how long it
took to process a login request in order to build a list of valid
usernames to use with brute force password guessing. Or attack an
appliance (slower CPU, easier target) that has a check of the form "if
this long token is equal to the provided value, grant access".

Imagine a customer web router with an XSS vulnerability in some
non-logged in portion of the interface (very common, especially in
help menus). Most of the security of the device lies in the fact that
the password is written on the bottom of it, and the interface is not
accessible from the public internet. With your new additions, a
javascript injection can work out the password for the device, one
character at a time. This is assisted by the fact that the device CPU
is slow and that the programmers didn't use a timing-independent
comparison function, but this attack would not be possible without the
level of detail you propose to add.

Unfortunately, the best mitigation I've come up with is to make the
feature entirely opt-in via header. Maybe this will encourage people
to take timing issues more seriously, but I doubt it. The balancing
act between features and security is always hard. This sounds really
useful, and the fact that it allows the exploitation of existing
issues probably shouldn't stand in its way.

-Paul

Received on Saturday, 8 October 2011 00:55:18 UTC