Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security Java

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.
This discussion has been archived. No new comments can be posted.

New Javascript Attack Lets Websites Spy On the CPU's Cache

Comments Filter:
  • by Anonymous Coward on Wednesday April 22, 2015 @03:03PM (#49530909)

    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.

    • It's called click bait. It keeps people like you coming to Slashdot and keep the site interesting (yes, this is a compliment).
      • by Anonymous Coward

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

      • by Nyder ( 754090 )

        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, Insightful)

      by Anonymous Coward

      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

      • by tepples ( 727027 )

        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.

    • Because that link has the exploit. (just kidding!)

  • Immune? (Score:3, Interesting)

    by Anonymous Coward on Wednesday April 22, 2015 @03:07PM (#49530947)

    AMD CPU and NoScript FTW!

  • by NotInHere ( 3654617 ) on Wednesday April 22, 2015 @03:08PM (#49530955)

    What has become out of bash styled mail address combination?

  • by Anonymous Coward

    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.

    • by Anonymous Coward

      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.

    • by viperidaenz ( 2515578 ) on Wednesday April 22, 2015 @03:56PM (#49531381)

      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.

      • by Anonymous Coward on Wednesday April 22, 2015 @05:01PM (#49531929)

        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.

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

  • by Anonymous Coward

    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

    • by hawguy ( 1600213 )

      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.

      • Does that implies that AMD CPUs are also 'vulnerable'?
      • by mysidia ( 191772 )

        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

        • by hawguy ( 1600213 )

          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.

      • by tgv ( 254536 )

        But Javascript?

        • by hawguy ( 1600213 )

          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

          • by tgv ( 254536 )

            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.

    • by vux984 ( 928602 )

      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

      • by DamonHD ( 794830 )

        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

        • by vux984 ( 928602 )

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

          • by DamonHD ( 794830 )

            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

      • by PRMan ( 959735 )
        People have already stolen bitcoin keys with a similar attack, so encryption keys are a definite possibility.
        • by vux984 ( 928602 )

          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

          • by AqD ( 1885732 )

            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.

    • 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

    • by jandrese ( 485 )
      It's a cache timing app. Pretty impressive that they were able to maintain the precise timing necessary to conduct the attack in Javascript, but still quite limited in what it can collect. Basically they can tell if certain cache lines are in use, and figure out maybe what those lines are shared with to do some behavior analysis on the victim. This application is a bit of a stretch, since learning the allocation patterns is not going to be easy.

      Their other example is a user that has a machine with tw
    • 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?

  • by vossman77 ( 300689 ) on Wednesday April 22, 2015 @03:26PM (#49531089) Homepage

    >Web browser using HTML5 (i.e., 80% of all PCs in the world)

    Internet Explorer 6 for the win.

  • 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?

    • 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?

      • 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?

    • by DarkOx ( 621550 )

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

      • 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

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

          • 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

    • 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

  • 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

  • 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 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?

    • by Anonymous Coward

      So, if one word is changed, everything would be correct? We call these things "typos", which everyone produces at some point.

  • by Anonymous Coward

    And people say I'm paranoid for using noscript...

  • Yet another example of the defective nature of the WinTEL Memory Management Unit.

    The Spy in the Sandbox – Practical Cache Attacks in Javascript [arxiv.org]
  • 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
    I mean, I've honestly been doing that since before no-script existed, did'nt all /. people?
    so, meh

    • Do you also wear a respiratory mask and rubber gloves when you visit public places?
    • by tepples ( 727027 )

      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?

  • 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?

  • Simply don't use it!

The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin

Working...