Slashdot Mirror
New Javascript Attack Lets Websites Spy On the CPU's Cache
An anonymous reader writes: Bruce Upbin at Forbes reports on a new and insidious way for a malicious website to spy on a computer. Any computer running a late-model Intel microprocessor and a Web browser using HTML5 (i.e., 80% of all PCs in the world) is vulnerable to this attack. The exploit, which the researchers are calling "the spy in the sandbox," is a form of side-channel attack. Side channel attacks were previously used to break into cars, steal encryption keys and ride the subway for free, but this is the first time they're targeted at innocent web users. The attack requires little in the way of cost or time on the part of the attacker; there's nothing to install and no need to break into hardened systems. All a hacker has to do is lure a victim to an untrusted web page with content controlled by the attacker.
http://arxiv.org/pdf/1502.07373v2
Thanks, dipshit editors, for not taking the 60 seconds to include the original paper, instead of linking to a Forbes article.
Source: http://arxiv.org/pdf/1502.0737...
Perl Programmer for hire
Does that implies that AMD CPUs are also 'vulnerable'?
RTFA:
It should be noted that the AMD cache
micro-architecture is exclusive, and thus the attacks described
in this report are not immediately applicable to
that platform
Such as this?
https://eprint.iacr.org/2013/4...
"We demonstrate the efficacy of the FLUSH+RELOAD
attack by using it to extract the private encryption keys
from a victim program running GnuPG 1.4.13. We tested
the attack both between two unrelated processes in a sin-
gle operating system and between processes running in
separate virtual machines. On average, the attack is able
to recover 96.7% of the bits of the secret key by observ-
ing a single signature or decryption round"
Rgds
Damon
http://m.earth.org.uk/
It can construct a data set across its virtual memory space that will cause an eviction of all the cache lines.
It then knows only it's own data is in the cache.
The next time it runs it can time how long it takes to access its own data, quick times mean no other process has used those cache lines. Longer access times mean another process has.
The attacking code can build up a memory access pattern of other processes on the machine. Each line is physically tied to a set of physical memory and there is also a co-incidental mapping to virtual memory pages.
If the attacking code knows exactly how the victim code works, it can find those access patterns and use them to determine which code branches it is likely taking. If that code is an encryption algorithm and you know what the plain or ciphertext data is, you can figure out what the key was.
The summary is wrong on by saying it's all Intel CPU's though. The attack was made for a specific Intel CPU, the Core i7-3720QM, where they know how it's 6MB of cache maps to physical memory. Any CPU with a different amount of cache will have a different mapping. There is no reason an AMD CPU couldn't be targeted.
Those attacks are about as similar as the matchbox car and the high speed train in my example above.
The kind of attacks that could extract bitcoin keys were monitoring certain system parameters like energy consumption with a very high resolution.
This attack can just say whether certain groups of memory locations that correspond to certain cache lines (which is a many-to-one relationship) have been accessed during a certain (rather long) time frame. We're talking a few hundred Hz resolution here. Good luck finding that bitcoin key. Or even a simple web address. OK, maybe visiting certain specific websites would show a specific memory usage pattern that might be recognized. So you'll know that the victim might have visited FaceBook. That's about the best you can do, and even that is pushing it. You're not going to find much more detailed data than that, the method is just too coarse.
Actually the summary is right for once (page 2 of the paper):
The Intel cache micro-architecture is inclusive – all elements in the L1 cache must also exist in the L2 and L3
caches. Conversely, if a memory element is evicted from
the L3 cache, it is also immediately evicted from the L2
and L1 cache. It should be noted that the AMD cache
micro-architecture is exclusive, and thus the attacks described in this report are not immediately applicable to
that platform.
I don't know what else they are wrong about but in the paper it says: "For example, the Intel Core i7-3720QM processor, which belongs
to the Haswell family, includes 8192 = 213 cache sets, each of which can hold 12 lines of 64 = 26 bytes each, giving a total cache size of 8192x12x64=6MB".
No, an i7-3xxx anything is in the Ivy Bridge not Haswell family but those cache characteristics would be correct for the Ivy Bridge i7-3720QM.
But if it was a Haswell it would be an i7-4xxx processor. So either they meant a last generation IVB processor or a different Haswell than they called out, but what they said is wrong.
Anyone see any other mistakes?
...read the paper.
it's like he said, you can detect that the network is being used or that there "probably was some user input".
which is pretty far away from keylogging, so far in fact that it's unlikely to be possible at all.
the whole paper up until that is written though as if you could snoop everything in the computer so not to blame you too much.
"e. Instead of the
traditional cryptanalytic application of the cache attack,
we instead showed how user behavior can be effectively
tracked using this method." you know why? BECAUSE THEY COULDN'T FUCKING EXECUTE A FUCKING SIDECHANNEL ATTACK!
world was created 5 seconds before this post as it is.