JavaScript CPU cache snooper tells crooks EVERYTHING you do online Four Columbia University boffins reckon they can spy on keystrokes and mouse clicks in a web browser tab by snooping on the PC's processor caches. The exploit is apparently effective against machines running a late-model Intel CPU, such as a Core i7, and a HTML5-happy browser – so perhaps about 80 percent of desktop machines …
“In the meantime the best suggestion I have for end-users is: close all non-essential browser tabs when you’re doing something sensitive on your computer,” he says.
Perhaps we could add the use of VMs designated specifically for web browsing to that recommendation, although I am not sure if this attack will allow the attacker to access info outside the sandbox. If it will, then it offers all sorts of opportunities for mischief in the data center.
RTFA!
The most eminently diligent python-wrangling boff has already considered VMs:
“Our attack, which is an extension of the last-level cache attacks of (Adelaide University's) Yuva Yarom, allows a remote adversary recover information belonging to other processes, other users and even other virtual machines running on the same physical host as the victim web browser.”
Other virtual machines yes, but I don't see how it could "read" outside of its own VM.
Assumption - I am running a browser. I also have two VMs running but the browser is on the base OS. The exploit can report whatever I do on the base OS and details of the VMs.
Assumption - I am running a browser in a VM. The exploit can tell an attacker about anything else inside that VM but cannot "see" outside it.
Assumption - I am running a browser in a VM. The exploit can tell an attacker about anything else inside that VM but cannot "see" outside it.
Actually, the isolation breaks down because the CPU cache is shared by the VM, the host OS and other VM:s. What gets difficult is cache-mapping keystrokes that do not go into the VM running the snooper, but I would not be surprised if some really smart boffin finds a way around this, too.
Re:VM's
But isn't the attack based on correlating web browser activity with the L3 CPU cache timings?
If the L3 CPU cache information can be inferred from a user process (from what I understand, you issue an instruction to evict a L3 cache line and read it as it is reloaded and infer what is happening based on timing memory accesses), virtualisation may make the attack more difficult due to additional activity but wouldn't defeat the attack.
This generation's "You can't hack me, I'm behind a NAT!".
In fact its becoming dangerous to rely on VMs to protect you now that a decent percentage of malware is now VM-aware (28% on the last report I read) with a few pieces here and there that even attack VMs specifically.
VM Aware? What do you mean? That they have the ability of executing systeminfo.exe ?
I don't actually know of anybody who obfuscates the fact the OS is running within a VM... I have seen some direct attacks at the likes of VMtools, but none that have been particularly successful.
Could you pass us some CVE details on which ones to look out for ?
"VM Aware? What do you mean? That they have the ability of executing systeminfo.exe ?"
They can use things like timing attacks (which rely on the unavoidable fact that the host can pause the guest when needed, creating timing gaps you wouldn't see on bare metal) and other tricks to learn they're in a VM (that's part of the thing, the guest shouldn't know it's in a VM). Right now, this means the malware won't operate properly when they detect this as this is meant to prevent researchers using VMs as honeypots. But given we already have sandbox-escape exploits, I say it's only a matter of time before we get a VM-escape exploit that attacks the hypervisor.
This attack seems an excellent opportunity to attack users of password managers. One enters their password at least once every 24 hours in the case of Lastpass, through an extension in the browser. For sites where higher security is needed one can set it up to request the master password again before permitting use of the site. Attacks which recover master passwords remotely would seem very useful to adversaries.
> "challenges the assumption that most side-channel attacks require snoopers to be in close proximity to their victims, and be able to execute arbitrary native code."
What assumption? We've had remote side-channel attacks for years, since at least Brumley and Boneh's "Remote timing attacks are practical" (USENIX August 2003), in which they "extract private keys from an OpenSSL-based web server running on a machine in the local network". There are others since then that have improved on the technique. So anyone who has been operating under such assumptions has been seriously not keeping up.
While not a perfect solution, having an add-in like NoScript on Firefox to block unnecessary JavaScript can help to reduce the likelihood of even having such JS code getting onto the browser in the first place.*
* situations where the malign JS manages to get into trusted JS sources can't be covered, of course.
Hmm. I'm generally of the opinion that if a site is designed in such a way that it is reliant on any Javascript for its layout, let alone 3rd party JS, then the designers need to rethink what the hell they've designed. Basic HTML5 and CSS3 should really be enough for everything except the most unusual situations, for which 1st party JS might be a fallback for. But, hey ho, that's probably just me.
The problem is leaking any information from one supposedly discreet process to another. But I get your point, this does seem to be just a start for further work rather than a usable exploit.
Makes you wonder how browsers can mitigate against this exploit without deliberately slowing stuff down to make it look like the cache was changed when it wasn't....
This post has been deleted by its author
It looks like they can detect that a mouse has been moved or that network activity has occurred. It's not the "we watched you typed your password" I was expecting from the article. They don't seem to know where the mouse went or what it did. Is it just a case of grabbing more data and finessing the algorithms to get it to be a real risk or is that a long way off?
It looks like the issue is caused by Intel's use of inclusive caches, so 80% of desktops are Intel:
From "The Spy in the Sandbox – Practical Cache Attacks in Javascript"
"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."
"Our attack requires a personal computer powered by an Intel CPU based on the Sandy Bridge, Ivy Bridge, Haswell or Broadwell micro-architectures. According to data from IDC, more than 80% of all PCs sold after 2011 satisfy this requirement."
So perhaps not "about 80 percent of desktop machines."
Interesting that they only goes back to Sandy Bridge which is the second generation. The first generation Core i processors with Nelahem or Westmere microarchitecture also have an inclusive L3 cache and would seem to be vulnerable as well. That would extend the period back to about 2008.
Nice call! Maybe they see that it was accessed from L1 timing, then read the data values remaining in L2 or 3. Intel has long traded off some cache duplication for the benefits of simplicity (and speed) in cache access. They used to have lower associativity, too (for similar tradeoffs) but now mostly match AMD. They'd have to remap the cache addresses to ones local to the process without repopulating the values to get around memory space isoloation. I think CFLUSH would let them do it.
Wow! Inclusive cache as security issue! And it simply ends any notion of VM isolation. A version of this that runs on servers could be bad news.
Main system :
Adjacent row reading in memory exploit : not vulnerable, ECC memory, Core2Quad based.
This cache exploit : Core 2 Quad, not vulnerable.
Firewall : pentium 3.
Course, there's a tablet (baytrail) and a shortly to be commissioned Ivy Bridge server. So I'm not in the clear, and at work there's both a load of old, not vulnerable stuff and new i5/i7 vulnerable kit..
I did that a few years ago, if you want to call it a screensaver. Probably not the first.
I've attempted enough JS game programming to have a pretty good idea how this attack works. Create a TypedArray containing the OS keyboard driver structure for each key. Every ~50ms, read them all, measuring each access time. If it's fast, and it was slow last time, that key was just typed.
Countermeasures: type your pw super fast. Transcode 5 videos at once to bust the cache. Stop everything to stagnate the cache. Run a program that simulates random key/mouse event structures used by all common OS drivers and other programs that handle keyboard input (good luck with that). Dump passwords in favor of keys, biometrics, etc.
This could be the Tacoma Narrows Bridge of future computer engineering 101 courses. :)
Thanks for the elucidation. I'm running on dual six core Xeons here which might scramble the samples so long as tasks aren't bound to one of the CPU's. Using affinities and then randomly change processor/core affinities perhaps to create more noise would be the likely mitigation. And noise, specifically the lack of it, is the real problem here. The ability on Intel processors to sample the contents of the L3, and by extension the L1 and L2, caches in a reduced noise environ allows this hack to work. (It's a energy/information leakage kind of thing. Heck if you look at the system under examination, it's very much a quantum system.) Having a bunch of cores on-hand, each tasked doing something, more than one cpu, would mitigate it to an extent.
I need to go through that paper again.
I suspect I'm essentially safe from this attack as I use both ECMAScript ('JavaScript') and ad blockers in all my web browsers. But it makes me sad that blocking these methods of revenue gathering over the Internet has become all the more crucial for maintaining both privacy and security. That HMTL5 is implicated is particularly sad. So much for progress in Internet security. So much for making Internet advertising friendly and helpful. :-P
User closes browser tab.
Solved.
Sorry, while I'm sure this is of academic interest I really don't see much use in the real world unless the javascript is somehow injected into a genuine webpage or its in a spoof webpage for a bank and suchlike but if they've managed to do that then there are much simpler ways to catch keystrokes.
First off, I'm very surprised that Javascript could run deterministically enough to be able to be useful for this.
That said, OK, so it can determine that a key was pressed. How could it possibly determine WHICH key was pressed? If one was (for instance) typing information into a form, wouldn't the computer get a very small delay from a keystroke, and take the same length of time to process the keystroke whether the user pressed any [a-z,A-Z,0-9]? (I specify letters and numbers because naturally tab or F1 for example would do something different.)
IIRC each key in the keyboard driver has its own subsystem. You ping each and every one on a regular basis and time how long it takes for them to respond. If one comes back faster than before, you likely have a cache hit, meaning it was used recently, between your pings. Just about the only way this could've happened is if someone used that key. Get it now?
Because that's only like that when the keyboard driver's finished with it. IN the driver, things are different because layouts can differ, keys may be added or missing, so the driver needs to keep an array for each of its keys so as to translate them appropriately. Suppose it's a dynamic keyboard able to change its layout; even more important there.
CPU cache side channel attacks are nothing new. They have been used to attack crytography and virtualized environments for years. The cache is predictable and therefore prone to attacks.
Modern operating systems and applications allready using randomization, now it's time for the hardware vendors to follow.
A fast and predictable cache may suit high performance and massive parallel workloads, but average Joe can browse the web without it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
