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.
AMD CPU and NoScript FTW!
What has become out of bash styled mail address combination?
Source: http://arxiv.org/pdf/1502.0737...
Perl Programmer for hire
They cant even describe what happens.
" Once there, the software inside the bogus content launches a program that manipulates how data moves in and out of a victim PC’s cache"
Uh, if the website can launch programs to manipulate your CPU cache, that's a problem.
I suspect this is the old "set up a webgl context, read back a framebuffer, maybe you will see some old shit in the framebuffer" attack that Microsoft used to attack WebGL back in the day.
Sounds like typical OMG COMPUTERS!!!!!!! from the business crowd.
God how I wish everyone with an MBA would just get the fuck out of my way when I have grownup work to do.
If you understand the CPU architecture, any program that can control what happens within its address space can manipulate data moving in and out of the CPU cache.
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
>Web browser using HTML5 (i.e., 80% of all PCs in the world)
Internet Explorer 6 for the win.
I suspect this is the old "set up a webgl context, read back a framebuffer, maybe you will see some old shit in the framebuffer" attack that Microsoft used to attack WebGL back in the day.
No. That's not it I don't think. (And the guard for that is trivial; zero the memory in all allocations.)
Although a user process shouldn't even be able to read "someone elses cache"; it should only be able to read from the cache something cached from its own process/address space so all it should be able to see is its own old shit.)
From my skim of the attack; I think its using high resolution timers plus carefully crafted memory usage to force the cache to flush/reload etc to detect "fingerprints" for certain types of activity... e.g. I could see how maybe one could craft a "signature" for what chrome looks like when loading a particular web page. Or a signature outlook starting up... etc.
And then you could watch for that sequence of cache event / timings (ie watch for the "signature" and discover with high reliability when that event happened.)
But I fail to see how this translates into being able to log keystrokes, steal encryption keys, steal data, or anything else.
It seems to me roughly the equivalent of monitoring the energy draw of a home and being able to determine when the fridge, stove, vaccuum, TV, or microwave, or hair dryer, are being turned on and off... provided you know what make and model of each they have. And then based on durations and so forth you can make educated guesses whether they heated some soup or are roasting a turkey, or whether its the short haired mother or the long haired daughter who is drying her hair...
Wow, it actually knows whether or not you moved the mouse, that's mega-hyper-dangerous! And the fact that you sent or received some unknown data over the network! Think of the possibilities!
I know side channel attacks have been used to extract AES keys, but that's like saying you can use a miniature matchbox car to transport hundreds of people at 300 km/h because things with wheels have been demonstrated to be capable of doing that.
The resolution of the detection system is cache lines, which are pretty big, and even though they are using system timers with nanosecond precision, actual sampling rate was a few hundred Hz. Good luck finding an AES key that way.
The covert channel is the only example that might be useful in very extraordinary circumstances: if the required apps are running on two VMs on the same machine, they can send data from one VM to the other. But on the other hand, aren't there plenty of other ways to do that? If you've already lured them onto an infection website, chances are the VMs are... connected to the internet and able to communicate that way.
So, unless I missed something, I don't think this is worth losing a lot of sleep over. Feel free to enlighten me if I'm wrong.
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's not so useless, Mr. Cafe. Case in point:
Bitcoin attack: https://eprint.iacr.org/2014/1...
GnuPG attack: http://www.nicta.com.au/pub-do...
ASLR attack: http://www.internetsociety.org...
All of these are cache-based side-channel attacks.
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.
The paper assumes that your problem is exfiltrating data because the target has somehow gotten infected but is ultra-paranoid about outbound traffic from his machine. You can instead transfer the data to a javascript app running in a webpage on a different VM that may be less secure. It seems pretty cornercase to me, but every time I think that someone comes out with some crazy exploit that extracts all of your SSH keys or something from the box using what seems like a nearly useless exploit.
I read the internet for the articles.
People have stolen bitcoin keys with a similar attack in the past. Bitcoin keys are just another form of encryption key. There are serious risks here.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
any program that can control what happens within its address space can manipulate data moving in and out of the CPU cache.
Yes, but it cannot observe what data from other processes is moving out of the cache The attacking process already has to know what bits the other process might have in the cache that they are attempting to time. The cache side-channel attacks are using statistical techniques... in artificially constructed scenarios: where only one other process has shared data you want to do a timing attack against.
It only works when the spying process knows the bits; And the timing at which those shared known bits are accessed, reveals information that can be used to infer other bits
Cryptographic algorithms are susceptible to this, BUT the algorithms and implementations can be made resistant through various methods.
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.
Let them have my cache. They can eat it, too.
The cache is a lie.
Faster! Faster! Faster would be better!
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?
Uh, if the website can launch programs to manipulate your CPU cache, that's a problem.
If a program can't manipulate the CPU, it's not much of a program now, is it?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
This mem.thrasher pgm will be a very fat piggy -- load one core 100% and slow everything else _way_ down. I don't know about you, but I slaughter such beasts on principle.
Should this mem watching ever become a threat (keystroke time-gap reading?) then an easy counter-measure is to detune the high-res timers, say zero out the lower 24 bits of rdtsc() in the JSlib. Still leaves ~10ms resolution but will break any attempt to time cache-reloads.
A keylogger that runs on one VM to spy on anther is a huge deal, if true. A great many companies rely on VM isolation to keep customers separated cleanly on the same host. The entire "compute" cloud, for starters.
What makes you think the apps need to run on both machines to leak data? CPU cache snooping can see almost anything.
You are running a browser on the VM's host???
In the free world the media isn't government run; the government is media run.
...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.
They did not demonstrate CPU cache snooping. The only thing the app can see, is whether or not certain cache lines have been used (and therefore, some of a whole lot of different possible memory locations may have been accessed). So, for example, if you can figure out that certain cache lines are used every time the user presses a key, you can watch those cache lines to have a rough idea of whether the user is typing or not. You don't know what's in those cache lines, just that they have been used. But since a cache line corresponds to a multitude of possible address ranges, you're not even sure which memory addresses were accessed. It could very well be some totally unrelated process doing totally unrelated things that happen to use the same cache line. But statistically, you get a better than average guess about what kind of activity is occurring on the other end.
The part you need two apps for, is where they demonstrated sending actual data from one VM to another. The app on one side (a keylogger, perhaps) accesses specific memory locations corresponding to specific cache lines. The app on the other side watches those cache lines by reading from them and timing how long it takes. If the location is read instantly, the process on the other side has not accessed that cache line, so that's a zero. If it takes slightly longer, the other side may have accessed it (or some totally unrelated process has), so that's a "probably one". Throw in some error correction, and you can slowly send data from one VM to the other.
There. Still scared?