New Javascript Attack Lets Websites Spy On the CPU's Cache 134
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.
Link to original paper (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:1)
It's called click bait. It keeps people like you coming to Slashdot and keep the site interesting (yes, this is a compliment).
Click bait?
Yes, this would be a perfect time to do that. Yes, let's do some of THAT shit while discussing how attackers are luring their victims to malicious content...and we wonder where they got the idea from...
Re: (Score:2)
It's called click bait. It keeps people like you coming to Slashdot and keep the site interesting (yes, this is a compliment).
Wow, someone has been drinking the New Slashdot Koolaid.
Re: (Score:3)
S/He could be complexly filigreed and still a douche.
Re: (Score:3, Insightful)
Hopefully you're aware by now that not all papers on arxiv have been peer reviewed.
Linking to forbes instead of arxiv shows that important people are taking the paper seriously.
Analogy time: There's no reason for anyone to bother reading one of the thousands of P vs NP proofs posted on arxiv, but we occasionally care when a famous CS prof says "shit, this might be right." When that happens, you'll see a link on slashdot to the professor's university page that links to the arxiv page. (Btw, so far they've al
Re: (Score:2)
There's no reason for anyone to bother reading one of the thousands of P vs NP proofs posted on arxiv, but we occasionally care when a famous CS prof says "shit, this might be right."
And this is why Wikipedia relies on reliable secondary sources, so that self-published bullcrap hoaxes don't compromise articles.
Re: (Score:2)
Because that link has the exploit. (just kidding!)
Re:all they have to do is lure them to a webpage (Score:5, Informative)
Source: http://arxiv.org/pdf/1502.0737... [arxiv.org]
Re: (Score:3, Insightful)
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,
Re: (Score:3)
Re: (Score:3, Informative)
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 f
Re: (Score:1)
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 worri
Re: all they have to do is lure them to a webpage (Score:2)
Re: (Score:2)
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.
Re: (Score:3, Interesting)
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???
Re: (Score:2)
Thin clients? Remote Desktop Services cluster?
This is in the context of the virtualisation *host* not the guests.
Re:all they have to do is lure them to a webpage (Score:5, Informative)
...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!
Re: (Score:2)
...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.
Re: (Score:2)
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 sinc
Re: (Score:2)
Immune? (Score:3, Interesting)
AMD CPU and NoScript FTW!
Re: (Score:2)
How is having your browser fail to work on many websites "FTW?"
Because if you want to ensure your security and privacy, you shouldn't use the web.
Home user administration of whitelists (Score:2)
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?
Re: (Score:1)
How is Tilda supposed to determine which domains are safe to whitelist?
Whitelist sites whose mission would justify spying, in case they do
.
Re: (Score:2)
Lemme think here. If the primary goal of the site is to spy on you, that site puts out some kind of bait for you to take. Failing to take the bait means you win. But, you see winning as breaking the internet?
It's like, you're a spy. The enemy puts the most beautiful woman on earth at your disposal, as bait. Use whichever movie plot you like - if you sleep with her, you die. If you don't sleep with her - then what? She's broken? You're broken? WTF?
Just don't take the bait. That doesn't "break the
Re:Immune? (Score:4, Insightful)
Considering what many websites consider "working" to be, "breaking" many sites IS the win.
I use noscript all the time, easily whitelist the few sites I WANT to "work" and things work so much better.
I get on a computer without noscript and I am astonished by all the cruft that passes for content. Use noscript for a week and you won't go back.
Re: (Score:3)
Re: (Score:2)
{yos | vpk | simha | angelos}@cs.columbia.edu (Score:4, Insightful)
What has become out of bash styled mail address combination?
Re: (Score:3)
Let them have my cache. They can eat it, too.
The cache is a lie.
x86 ecosphere horribly broken (Score:1, Interesting)
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.
Re: (Score:1)
I don't know if you read the paper or not, but it can only observe whether or not a CPU cache location has changed or not.
The paper suggests that security countermeasures would probably have performance impact, so the features seem to have been more about speed than bells and whistles.
Re:x86 ecosphere horribly broken (Score:5, Informative)
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.
Re:x86 ecosphere horribly broken (Score:5, Informative)
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.
Re:x86 ecosphere horribly FIXABLE (Score:3)
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.
I call bullshit on anything from Forbes (Score:1)
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 busines
Re: (Score:3)
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.
Re: (Score:2)
Re:I call bullshit on anything from Forbes (Score:5, Informative)
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
Re: (Score:3)
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 ti
Re: (Score:2)
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.
Well yeah, that's kind of what the whole paper is about - the fact that they can analyze cache behavior to detect network and mouse activity on the system.
Re: (Score:2)
But Javascript?
Re: (Score:2)
But Javascript?
RTFA:
Two specific
APIs which are of use to us in this work are the
Typed Array Specification [9], which allows efficient access
to unstructured binary data, and the High Resolution
Time API [16], which provides sub-millisecond time
measurements to Javascript programs
Re: (Score:2)
Wow, I did not believe this. I skimmed the article, and that's quite impressive. I don't see how to could do anything more nefarious than some observations on user activity with just Javascript, but thanks for pointing it out.
Re: (Score:3)
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 cert
Re: (Score:2)
http://en.wikipedia.org/wiki/N... [wikipedia.org]
[citation provided]
I know someone who can do that right now for appliances, probably previously unseen.
Thus with a big enough incentive (such as getting access to your bank account) the danger is real.
Rgds
Damon
Re: (Score:2)
Oh I know it can be done; but thanks for providing the proper name, acronym, and citation.
Thus with a big enough incentive (such as getting access to your bank account) the danger is real.
But that's what I'm not seeing. The cache usage fingerprinting, at worst, knows when I visit my bank*
But it can't steal my bank account number or password. Whether my password is 1-2-3-4 or 4-3-2-1 is not going to be discernible from a cache timing side channel attack. They won't get my bank account number either.
At worst they might be able to guess how many characters it is.* (And only if I type it... which I don't...
Re: (Score:2)
Look elsewhere in this story: I've posted a 2013 paper where using this type of attack it appears that very nearly 100% of your secret key bits can be recovered as you do a single encryption in another process.
Note: not just revealing that I did an encryption, but what the bits of the key were that did it.
*That* seems bad enough to need serious thought (or refutation) ASAP.
Rgds
Damon
Re: (Score:2)
Re: (Score:2)
Ok, that's fair. Although the bitcoin attack amounted not to reading any data, but rather deducing the key over watching several iterations of it being used to encrypt. So they were able to get some insight into what the key must be by watching how the hashing algorithm operated using it.
Neat stuff.
A theoretical similar attack might be to watch a browser use its https session key to grab the key, and then allow a malicious user to decrypt the https stream (assuming they had a separate means to capture / rec
Re: (Score:1)
A theoretical similar attack might be to watch a browser use its https session key to grab the key, and then allow a malicious user to decrypt the https stream (assuming they had a separate means to capture / record that...) and that would be pretty bad.
But you still have to repeat the same encryption/decryption enough times to detect anything close. It might be easily defended by simple and random obfuscation to make the detection much more difficult (ex: running multiple encryption/decryption by different keys at the same time), or moving the entire code into GPU, where operations are asynchronous and timing cannot be accurate.
Re: (Score:1)
They can't even do that. All they can see is whether or not certain areas of memory have been accessed. They write something to a specific location to use a line in the cache and thereby invalidate it for other apps. Then, some small amount of time later, they read from that same location and time how long it takes for the data to arrive. If it takes longer, that means the cache line has been invalidated and therefore some other process must have accessed the memory that uses the same cache line. That gives
Re: (Score:2)
Their other example is a user that has a machine with tw
Re: (Score:3)
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?
Re: (Score:2)
Re: (Score:2)
The problem isn't necessary running untrusted code. The problem is that the code can without any notice to the user send arbitrary data pretty much anywhere. 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.
Read this comment: Cancel or Allow? (Score:2)
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.
Re: (Score:2)
Yup, not just cheaper but safer.
Too bad intel probably already tasked a dozen engineers to expand this to cover AMD as well.
Internet Explorer (Score:5, Funny)
>Web browser using HTML5 (i.e., 80% of all PCs in the world)
Internet Explorer 6 for the win.
Re: (Score:2, Funny)
You will be stoned to death for suggesting this. LOL!!
lure a victim to an untrusted web page (Score:2)
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?
Re: (Score:1)
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?
Do you trust Forbes?
Re: (Score:2)
Do you trust Forbes?
Not at all, but I get your point. OTOH why are you letting every Tom, Dick and Forbes run code, "sandbox"ed or not, on your computer?
Re: (Score:1)
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?
Beware what you have said is dangerously near to the sort of statement that bring the Social Justice Warrior types down on you. Just encase you missed the memo, we are no long allowed to chastise people for engaging in overly risky, and ignorant behavior, its not longer their failing in the form of lack of personal responsibility, but yours and mine in that we are are "victim blaming".
Re:lure a victim to an untrusted web page (Score:2)
Goodness me, is there no enormity that SJWs won't stoop to?
Yeah, the reason I rant about the blatant stupidity of the term "SJW" if because of idiots like you. You've somehow managed to make an article about side channel attacks and leaky sandboxes with javascript about "social justice warriros".
Because it's totally impossible for a whitelisted website to get hacked.
Moron.
And speaking of which... whitelists? Which year is it? You know written directories of all the websites in the world went out of style in
Good case for turning scripting on (Score:2)
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 [wikipedia.org], it becomes hard to define "a good case".
Re: (Score:2)
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.
It's a good job no sites ever have well hidden malware.
So, apparently SJWs are evil because without them we'd have to be 100% vigilant the entire time when surfing the web and it's their fault we're not? It's amazing what people ascribe to SJWs these days!
Besides, it's not like quit
Re: (Score:2)
Do a Google search, end up on some random web page. Do you trust that website? Then why the fuck is your computer letting it run scripts?
Now, take the embedded scripts linking across a dozen or so sites which also ran in that page. Do you trust any of them? Why the hell would you? Why the fuck is your computer running them, then?
The problem is that the web has been more or less set up so that you will encounter websites you neither know nor trust all the time ... and unless you're fairly paranoid and p
Not very useful. (Score:2)
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 tech
To make it clear. (Score:2)
This is just detecting which cache lines are in heavy use at a moment in time, not WHAT'S IN THEM.
Very useless.
Re: (Score:3, Interesting)
It's not so useless, Mr. Cafe. Case in point:
Bitcoin attack: https://eprint.iacr.org/2014/1... [iacr.org]
GnuPG attack: http://www.nicta.com.au/pub-do... [nicta.com.au]
ASLR attack: http://www.internetsociety.org... [internetsociety.org]
All of these are cache-based side-channel attacks.
Re:Not very useful. (Score:4, Informative)
Such as this?
https://eprint.iacr.org/2013/4... [iacr.org]
"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
Re:Not very useful. (Score:4, Interesting)
Sorry, I tried to resist... (Score:2)
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". ;-)
Accuracy of the paper is suspect already... (Score:5, Informative)
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?
Re: (Score:1)
So, if one word is changed, everything would be correct? We call these things "typos", which everyone produces at some point.
Re: (Score:2)
What the hell keyboard are you using where mistyping ivy bridge results in the word Haskell?
Beautiful.
Noscript (Score:1)
And people say I'm paranoid for using noscript...
Defective WinTEL MMU .. (Score:1)
The Spy in the Sandbox – Practical Cache Attacks in Javascript [arxiv.org]
good thing all of us use no-script add on 100% (Score:1)
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
Re: (Score:1)
Re: (Score:2)
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
How do sites become "100% known sites" to you?
This is why Amazon offer dedicated instances (Score:2)
Amazon AWS offers 'dedicated instances' [amazon.com] (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?
Javascript is Evil (Score:1)
Re: (Score:2)
Who forgot to close the door and let the markedroid in?
Re: (Score:2)
You really have no clue. Everything the CPU loads from memory goes into all cache-levels. That is how a cache works, you know.
Re: (Score:2)
Actually, while it sounds hard, such leakage can be quite enough to get crypto-keys from memory. Sure, you may have to try a few billion times, but that is really not a problem.