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.
And then they find out nothing.
This doesn't let them look at anything they couldn't look at without this attack.
If you went to some certain webpages really recently then it might be able to discover you did so.
And that's it.
http://lkml.org/lkml/2005/8/20/95
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.
Apps that app apps get apped when appers app other apps!
Apps!
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.
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!
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.
The processor's cache? Nothing typically enters that except high level math that needs to be done rapidly. You'd basically never see a string in there because string manipulation doesn't benefit from processing in hyper-fast flash cache. So if you stole the cache data, you'd be looking at a bunch of useless numbers and gibberish.
And we all know who's behind this.
That's right!
GCHQ!
Thanks a fucking lot.
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?
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.
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
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...
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.
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!
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".