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?
Let them have my cache. They can eat it, too.
If an interpreted language, running in a user context, can somehow observe what's in CPU cache, then something is really, very broken.
As long as people trade security for features, this crap is inevitable.
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.
Source: http://arxiv.org/pdf/1502.0737...
Perl Programmer for hire
A paper saying they discovered that javascript runs slower when a computer is busy doing other things at the same time?
So, once again, as we step into yet another iteration of the browser as arbitrary execution environment, we find that it's leaky.
Which is the very argument that is made for throwing out the previous iteration (Java applets, Flash, ActiveX, etc.) every time.
Now can I please have a browser that doesn't run arbitrary code unless I give it permission?
AMD FTW
>Web browser using HTML5 (i.e., 80% of all PCs in the world)
Internet Explorer 6 for the win.
try "Sandy Bridge, Ivy Bridge, Haswell, and Broadwell micro-architectures".
Anyone have a POC?
umm, all I need to do is lure a victim to my untrusted dumpster, and I can do all sorts of bad things to them.
The problem isn't that there's a way for me to hurt you. The problem is that you're walking down dark alleys alone at night.
Stop doing that.
Why are you going to untrusted web-sites in the first place?
at most you could use this to have an infected process communicate indirectly with a javascript process by tying up cache lines - and the javascript could detect that.
But so what? If you've already installed malicous code, why does it have to communicate indirectly?
You're not going to be able to tell much useful about a machine by getting a very low quality of image of what cache lines are in heavy use at the moment when you DIDN'T write the programs being used.
This sounds like a useless fingerprinting technique.
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.
This is just detecting which cache lines are in heavy use at a moment in time, not WHAT'S IN THEM.
Very useless.
Yup, not just cheaper but safer.
Too bad intel probably already tasked a dozen engineers to expand this to cover AMD as well.
I don't suffer from insanity, I enjoy every minute of it!
Who forgot to close the door and let the markedroid in?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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 computer running a late-model Intel microprocessor and a Web browser using HTML5...is vulnerable to this attack.
Which brings a whole new depth of meaning to "Intel Inside". ;-)
I've calculated my velocity with such exquisite precision that I have no idea where I am.
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.
Attacks only get better, never worse. You have to prove _why_ the technique could never be improved to become more of a problem. Both the limitations of the proof of concept, as well as your general intuition are completely meaningless, except as rough guides to prioritizing your threat mitigation measures in the short term.
There are all kinds of theoretical side channel attacks. What distinguishes this one is that it has evolved from theory to practice. That the particular practical attack isn't very worrisome is of little matter. It's a _huge_ step from theory to practice, compared to subsequent improvements. That, and the lack of a proof that forecloses or at least constrains improvements, is all you need to know to take it seriously.
Ummmmm, no. I could go into the details here, but I won't because literally 2 seconds of research as to how standard computer memory architectures work will explain why you are wrong. It's literally common knowledge if you work in IT on why you are wrong. All data goes through the cache. It has to. That's how the architecture is laid out.
And we all know who's behind this.
That's right!
GCHQ!
Thanks a fucking lot.
There are serious risks here.
Only for those who take 'encryption' seriously, believing you need anything more than a Captain Crunch Code Ring to break. Encryption is NSA snake oil. Roll something of your own, or use the classifieds to communicate.
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?
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.
Socialism: a lie told by totalitarians and believed by fools.
And people say I'm paranoid for using noscript...
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.
The reason I get html 5 errors on youtube?
Yet another example of the defective nature of the WinTEL Memory Management Unit.
The Spy in the Sandbox – Practical Cache Attacks in Javascript
...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.
A process can measure memory access latency to determine that *something* else on the system *somewhere* has touched some memory *somewhere* that is on a shared cache line with the spy process... and somehow from there you can magically figure out not only that that some process somewhere is doing something like writing an aes key to some memory somewhere and.... and... you still can't see what that key is...
The side channel communication was kind of cool though (Usenix!) But seems completely useless unless there is another application looking for it. Its a web script that has to run at-least a minute and even then the author states it only gets 50% of the cache lines. Its easier to do a code injection in one of the wonderful holes in un-patched XP computers out there than do this kind of mission impossible.
You really have no clue. Everything the CPU loads from memory goes into all cache-levels. That is how a cache works, you know.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
good thing all of us use no-script add on for 100% of the sites we visit, and ONLY turn it on for 100% known sites /. people?
I mean, I've honestly been doing that since before no-script existed, did'nt all
so, meh
This mem.thrasher pgm will be a very fat piggy -- load one core 100% and slow everything else _way_ down.
That sounds perfectly normal for modern web pages that use Javascript or Flash.
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?
...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".
With a bit higher sampling though, you can significantly narrow the likely password range, simply by using the timing of key presses.
But yeah, I want to see something like that demonstrated before worrying about it.
Amazon AWS offers 'dedicated instances' (ctrl-f for "Dedicated Instances") for security reasons.
for workloads where corporate policies or industry regulations require that your EC2 instances be physically isolated at the host hardware level from instances that belong to other customers
Anyone know if this attack would actually work today on, say, Amazon's shared-hosting?
Simply don't use it!
Thin clients? Remote Desktop Services cluster?
Say an inexperienced end user (call her Tilda) is using a browser on which a (perhaps more experienced) user has installed NoScript. How is Tilda supposed to determine which domains are safe to whitelist?
JavaScript should require user permission to load/post data. This would help with the awful interfaces out there that arbitrarily load data incurring additional network requests and latencies.
A "Cancel or Allow" box for every XMLHttpRequest or for every created DOM element that has a src attribute would be even more tiring for the user than Windows Vista UAC.
You know written directories of all the websites in the world went out of style in 1996? So how are you supposed to find new ones then?
I think the idea is that you discover a site using a search engine or articles posted by your friends and then visit the site with scripting turned off, and the site has to make a good case for turning scripting on for that site. But with end users being willing to do anything to see the dancing bunnies, it becomes hard to define "a good case".
Thin clients? Remote Desktop Services cluster?
This is in the context of the virtualisation *host* not the guests.
In the free world the media isn't government run; the government is media run.
But isn't the whole point that this could be run in a guest to spy on other guests?
Sounds like somebody couldn't figure out how to set up GPG.
I remember sigs. Oh, a simpler time!
Like I said, snake oil! Don't be so naive... Besides, the 'meta-data' is just as good.