back to article 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 …

  1. Robert Helpmann??
    Childcatcher

    And Another Thing

    “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.

    1. Antonymous Coward
      Boffin

      Re: And Another Thing

      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.”

      1. dogged

        Re: And Another Thing

        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.

        1. MacroRodent

          Re: And Another Thing

          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.

        2. theblackhand

          Re: And Another Thing

          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.

      2. Robert Helpmann??
        Paris Hilton

        Re: And Another Thing

        RTFA!

        Yup. Missed that. Falling on my (virtual) sword now.

    2. Crazy Operations Guy

      Virtual Machines for security

      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.

      1. Zacherynuk

        Re: Virtual Machines for security

        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 ?

        1. Anonymous Coward
          Anonymous Coward

          Re: Virtual Machines for security

          "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.

  2. Aslan

    Opportunity to attack password managers

    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.

  3. Anonymous Coward
    Anonymous Coward

    Assumptions?

    > "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.

    1. A Non e-mouse Silver badge

      Re: Assumptions?

      So far, though, they don't appear to have extracted any part of the key: They've just shown they can see memory usage.

  4. Anonymous Coward
    Anonymous Coward

    "...and even other virtual machines running on the same physical host"

    Ouch! Now that is nasty.

  5. Novex

    Disable JavaScript?

    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.

    1. Crazy Operations Guy

      Re: Disable JavaScript?

      Unfortunately, most websites require 3rd party JavaScript to not look like a pile of mess...

      1. Caspy7

        Re: Disable JavaScript?

        NoScript let's you choose what javascript loads (such as from what origin). It's not just turning off javascript.

        I'd also throw in uBlock which allows you to block more than just ads (and is much better on performance & memory usage).

      2. Novex

        Re: Disable JavaScript?

        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.

  6. Vimes

    which can be performed by JavaScript served from a malicious web ad network

    Given problems in the past, potentially *any* ad network could be subverted for malicious purposes.

    How many such networks does this site use, and will you ever be offering a paid option to remove ads entirely?

    1. Crazy Operations Guy

      I use an ad-blocker but make up for it by buying swag in the store.

  7. The Mighty Spang

    whats the problem?

    unless you can tell what key was pressed or what was clicked, whats the problem?

    1. sabroni Silver badge

      Re: whats the problem?

      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....

      1. This post has been deleted by its author

      2. Crazy Operations Guy

        Re: whats the problem?

        "slowing stuff down"

        Or just chop off the LSB on the high-resolution timers. Cut off two or more for safety. Maybe set the actual resolution to be tied to how trusted the site is.

    2. djack

      Re: whats the problem?

      I've learned a long time ago that just because you can't see an attack vector it doesn't mean that nobody else can.

      It's scary how many potential vulnerabilities end up losing the 'potential' bit.

      1. Gordon 11

        Re: whats the problem?

        What about having lots of other processes doing other things on your system which will affect the L3 cache in random (unpredictable) ways even while you are typing?

  8. sabroni Silver badge

    Clever but how dangerous?

    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?

  9. Steve Graham

    cat /proc/cpuinfo

    80% of desktop machines in the world have i7 processors?

    1. theblackhand

      Re: cat /proc/cpuinfo

      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."

      1. Steve Graham

        Re: cat /proc/cpuinfo

        Still on a Core 2 Duo here. No L3 cache.

      2. Rimpel

        80%

        "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."

        1. Anonymous Coward
          Anonymous Coward

          Re: 80%

          "about 80 percent of desktop machines" in the world of optimistic marketing guff

        2. Eddy Ito

          Re: 80%

          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.

        3. jason 7

          Re: 80%

          I was going to say, that's not what I see in the real world of computing. Most are lucky to have a dual core C2D.

          I still go "ohh an i3/i5...very swish!" if I spot one. If on the rare occasion I spot an i7 I'm gob smacked.

      3. Federal

        Re: cat /proc/cpuinfo

        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.

    2. BinkyTheMagicPaperclip Silver badge

      The second time I'm covered for still running an old platform!

      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..

  10. The Mighty Spang

    I've got it now.

    Its so you can develop the world's first javascript screensaver.

    1. Anonymous Coward
      Anonymous Coward

      Re: I've got it now.

      You're evil.

    2. Anonymous Coward
      Anonymous Coward

      Re: I've got it now.

      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. :)

      1. Nick Ryan

        Re: I've got it now.

        Aha. If that is the case then thanks for explaining just how this thing might be a vaguely useful exploit.

      2. Anonymous Coward
        Thumb Up

        Re: I've got it now.

        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.

      3. Unlimited

        Re: Countermeasures: type your pw super fast

        Or super slow?

        Type 1/3 of password

        Write that email you've been meaning to send

        Type 1/3 of password

        Reply to some forum posts

        Type 1/3 of password

        Login!

  11. Florida1920
    Pint

    NoScript, AMD Athlon II X4 CPU

    "AMD's Athlon II X4 represents the first monolithic quad-core die without a shared L3 cache."

    It's pub-o-clock!

  12. DerekCurrie
    Unhappy

    *sigh* Another Reason To Block 'JavaScript' and Ads

    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

  13. Anonymous Coward
    Anonymous Coward

    From what I can tell...

    ...Oracle don't really care about Java security.

    1. Destroy All Monsters Silver badge

      Re: From what I can tell...

      Trolls aren't even trying anymore.

    2. DelM

      Re: From what I can tell...

      While Oracle may not really care, they are not relevant to JavaScript. I.e, Java is not JavaScript.

  14. Anonymous Coward
    Anonymous Coward

    We need true process isolation

    These OS architectures are a mass of side-channel activity.. we need true process isolation through the kernel and all the way down to the hardware.. there is some research going on in this area, like Genode.

    1. Anonymous Coward
      Anonymous Coward

      Re: We need true process isolation

      Or maybe allowing a program to download and execute relatively powerful script programs - albeit in a sandbox - was a bad idea in the first place and should be slowly backtracked on.

  15. Anonymous Coward
    Anonymous Coward

    Solution

    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.

    1. Charles 9

      Re: Solution

      They can achieve the former with a drive-by attack, usually by means of an ad network (and more sites are incorporating ad-blocker-blockers so that you have to take the ad in order to view the exclusive, not- available-anywhere-else content).

  16. Henry Wertz 1 Gold badge

    How does this work?

    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.)

    1. Paul Crawford Silver badge

      Re: How does this work?

      I don't see how they can tell (yet?) which key was pressed, but they might be able to find out your password's length and so target brute-force on a subset of users with short-ish passwords.

    2. Anonymous Coward
      Anonymous Coward

      Re: How does this work?

      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?

      1. Anonymous Coward
        Anonymous Coward

        Re: How does this work?

        "IIRC each key in the keyboard driver has its own subsystem."

        Huh? Why on earth would it? A "key" is just a numeric value.

        1. Anonymous Coward
          Anonymous Coward

          Re: How does this work?

          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.

          1. Anonymous Coward
            Anonymous Coward

            Re: How does this work?

            Thats not a subsystem - thats just a mapping.

  17. IGnatius T Foobar

    Why bother?

    Why bother snooping? Most people willingly *give* all of their personal information to Faecesbook every day.

  18. Nathan Brathahn
    FAIL

    no software issue

    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.

    1. Charles 9

      Re: no software issue

      Trouble is, there are "Average Joe" jobs that ALSO require high performance. Such as video encoding (home movies) or gaming.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like