9

Potential timing attacks are always brought up in one context or the other but I don't think I've ever read a case where someone has actually executed such an attack over the internet.

6

It might be tempting to assume that network latency (jitter) makes these attacks impractical. This is not the case because TCP timestamps are often used by the vulnerable machines, where the precise time the packet was generated is encoded into the TCP header. No matter how long it takes the traffic to arrive, the exact time it was created is still present. Even on systems with timestamps disabled, it is possible to get an accurate idea of the packet timing by repeating the test multiple times and averaging the result to account for network jitter. So, with that in mind...

Yes, timing attacks can be done over a network. The most prominent example was a long-lived vulnerability in OpenSSH that allowed trivial user enumeration. The issue was caused by the fact that an invalid user would trigger password comparison using Blowfish, the default. When a valid user was used, SHA-2 would be used instead. While normally the timing difference is minimal, sending a large password (several kilobytes) would cause the difference to be noticeable.

From the original bug disclosure:

When SSHD tries to authenticate a non-existing user, it will pick up a fake password structure hardcoded in the SSHD source code. On this hard coded password structure the password hash is based on BLOWFISH ($2) algorithm. If real users passwords are hashed using SHA256/SHA512, then sending large passwords (10KB) will result in shorter response time from the server for non-existing users.

Attacks against these types of bugs often exploit the fact that a different code path is taken depending on the input you provide, causing a significantly greater timing difference than is typically seen with low-level architectural timing attacks where the differences are measured in nanoseconds and come from instructions not executing in constant time (flush+flush, etc).

1

As the discussion on this question about a user enumeration threat based on a timing attack illustrates... timing vulnerabilities can crop up any time a different amount of work is needed to return a result, even if the rendered page is not designed to disclose the information that was used in processing the request.

The linked question refers specifically to a user enumeration vulnerability, but similar timing differences could happen in any authorization scheme that requires a resource to be fetched and permissions checked before it can be determined if the authenticated user has permission. It might be possible to discern, for example, if a user has a certain feature enabled on their account, because the authorization logic is more complex and takes longer to run.

The severity of such a vulnerability would depend entirely upon the sensitivity of the information that would be disclosed by the attack.

  • It seems user enumeration vulnerabilities are common with timing attacks. Your answer reminded me that OpenSSH recently had such a vulnerability! – forest Apr 16 '18 at 11:39
0

Yes, of course, because one of those attacks is Spectre! The attack against the CPU cache timing is known for its potential of being carried out with Javascript, revealing critical user data, stored in a browser, to an arbitrary Web site.

(By the way, this illustrates the idea: remote timing attacks might sometimes be viewed as something almost harmless, but they might play a role of a solid ground for more sophisticated attacks, build on top of other vulnerabilities and too hard to be tracked down. E.g. if at some point there will be even an apparently harmless clientside vulnerability, a timing attack may easily evolve into a severe problem.)

The reason timing attacks were always believed to be infeasible over the Internet was, basically, the round-trip time which adds a considerable margin of error, which in turn is assumed to make timing issues very obscure to a remote party. However, generally, RTT is something which, in most cases, given a good connectivity both on the victim's side and on the attacker's side (which is something too easy to achieve), statistically, is stable enough. Timing issues are also stable for that matter.

If an attacker is able to do a lot of attempts to collect enough data to do statistic measurements, they can generally make an adjustment for RTT, effectively removing this vague obfuscation of the execution time measurements. Here's another practical example of how it can be done.

Timing issues are not something to underestimate.

  • 3
    I'd argue that this doesn't count as a remote timing attack because it's just local JS that may be fetched from remote once. – Arminius Apr 15 '18 at 22:53
  • 4
    Well, I'd think OP's main point is what you rightly picked up in your answer yourself - whether high RTTs make timing attacks impractical. However, you gave an example where latency is irrelevant, which seems like a bit of a bypass. :-) – Arminius Apr 15 '18 at 23:48
  • 1
    @Arminius I've just discovered that I'm dumb enough not to read the question carefully. The question is explicitly phrased to be about the attacks "executed over the Internet". The discussion about Spectre being local or remote may last long, but, as a matter of fact, it definitely can be executed over the Internet ;-) Your comment about adjacent attacks is completely valid. – ximaera supports Monica Apr 16 '18 at 0:17
  • 1
    Spectre is not executed over the internet and cannot be. Malicious code can be sent over the internet, but it will only ever be executed on the client. If a server-side language could exploit Spectre on a remote client without that client locally executing a client-side language, then this would be correct. – forest Apr 16 '18 at 10:01
  • 1
    Come to think about it, you could make an argument that any and all exploits involving execution are remote, which would be plain silly. This answer is just misleading. – forest Apr 16 '18 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.