Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Java Security Operating Systems Privacy Software The Internet Hardware

JavaScript Attack Breaks ASLR On 22 CPU Architectures (bleepingcomputer.com) 157

An anonymous reader quotes a report from BleepingComputer: Five researchers from the Vrije University in the Netherlands have put together an attack that can be carried out via JavaScript code and break ASLR protection on at least 22 microprocessor architectures from vendors such as Intel, AMD, ARM, Allwinner, Nvidia, and others. The attack, christened ASLRCache, or AnC, focuses on the memory management unit (MMU), a lesser known component of many CPU architectures, which is tasked with improving performance for cache management operations. What researchers discovered was that this component shares some of its cache with untrusted applications, including browsers. This meant that researchers could send malicious JavaScript that specifically targeted this shared memory space and attempted to read its content. In layman's terms, this means an AnC attack can break ASLR and allow the attacker to read portions of the computer's memory, which he could then use to launch more complex exploits and escalate access to the entire OS. Researchers have published two papers [1, 2] detailing the AnC attack, along with two videos[1, 2] showing the attack in action.
This discussion has been archived. No new comments can be posted.

JavaScript Attack Breaks ASLR On 22 CPU Architectures

Comments Filter:
  • by nuckfuts ( 690967 ) on Wednesday February 15, 2017 @07:13PM (#53877035)

    In layman's terms, this means an AnC attack can break ASLR...

    'cause every layman knows what ASLR is.

    • Re:Layman's Terms (Score:5, Informative)

      by El Cubano ( 631386 ) on Wednesday February 15, 2017 @07:19PM (#53877069)

      'cause every layman knows what ASLR is.

      I had the same thought. At first I thought it was related to digital photography. Here is what this is really all about: https://en.wikipedia.org/wiki/Address_space_layout_randomization [wikipedia.org]

      In layman's terms: Keeping the locations of things in memory unpredictable so that, for example, if I am trying to exploit some arbitrary code execution flaw I can't count that my code will end up in the place I want or expect it.

      • by Dunbal ( 464142 ) *
        Turns out it's not as random as they would want you to believe...
        • by DontBeAMoran ( 4843879 ) on Wednesday February 15, 2017 @10:39PM (#53877977)
          • by Anonymous Coward

            I really like the Dilbert one.
            Any true random number generator should be able to output an infinite sequence of nines.
            If it can't then it has a statistical distribution that makes it predictable.

        • by Anonymous Coward

          Eh, it *is* as random as the people who wrote ASLR said it was. It is also nearly as useless as the people behind GR-SECURITY said it would be ;-)

          The problem is that cache aliasing can be used to do a timing attack, and the timing attack can tell you where other important stuff is. This is a conceptual thing, so it affects pretty much everything that implemented memory caches, as they really share the same basic concepts.

          The solution is also known, but *NOT* widely available in hardware (and certainly not

      • Keeping the locations of things in memory unpredictable so that, for example, if I am trying to exploit some arbitrary code execution flaw I can't count that my code will end up in the place I want or expect it.

        Close but not quite right.

        Its so that you can't count on OS/Host code being at a specific address. Your own code doesnt need to care what address its loaded at, even if its nefarious (every architecture has relative jump instructions.) The idea is that something like the browsers file i/o routines arent being placed at a predictable address, so your nefarious code cant just branch directly into them.

        The main flaw of address randomization is that address information can still leak through the stack if y

        • by sjames ( 1099 )

          Of course, the bad code could also scan the process memory space to find the relocation table.

    • by geek ( 5680 )

      In layman's terms, this means an AnC attack can break ASLR...

      'cause every layman knows what ASLR is.

      Do you know what Google is? I know, it's hard right?

      • For what's it's worth, I was already familiar with that acronym. I was questioning whether a layman would be.

        You seem to be confusing "Layman's terms" with "Anything that can be looked up on Google".

      • by Anonymous Coward

        I know what Google is, and Startpage, and DuckDuckGo, amongst others, and it isn't hard.

        It also isn't hard to write "Address Space Layout Randomization (ASLR)" the first time the acronym is used in a text when the total effort of all the people who are going to to look it up is likely to be much larger than the effort to type those words. Yes. that is someone else's effort and not yours when you write a text, but if others do the same you benefit from that, and the total text effort of humanity while readin

      • "Do you know what Google is? I know, it's hard right?"

        Google (as a meta service) also relies on people explaining terms somewhere on the web...

    • easy... http://lmgtfy.com/?q=ASLR [lmgtfy.com]
    • by Anonymous Coward

      All your base address are belong to us. Somebody set up us the bomb. Let's fighting love. I'm so Ronery.

  • by Anonymous Coward

    It's been every few days since javascript even came onto the scene that we have seen some exploit using javascript as an attack vector.

    It is a fundamentally flawed idea to run javascript that any random site happens to deliver to you. The number of ways that can go badly seems to be effectively endless.

    If you care at all about the security of your machine, you should not be running javascript by default. This is where a bunch of people come out of the woodwork to say "but we need it to view $RANDOMSITE!

    • by Anonymous Coward

      The "exploit" could be expressed in any language -- it has nothing to do with Javascript intrinsically. The point is that something as high level as js can perform the aslr observation.

      • by Anonymous Coward on Wednesday February 15, 2017 @08:28PM (#53877473)

        OK, fair enough, but if it's expressed in another language (assuming it's not part of your OS) you have to explicitly get and run the malicious software. If it's javascript you get it just by visiting a web page with default browser settings.

        Delivery is different, even if in theory you could get it via some other means.

  • I only hope (Score:2, Funny)

    by Anonymous Coward

    Somebody can tell me how I can block this attack with a HOSTS file?

    • Why was THIS modded down? This would actually work... to some degree, if you had all the ad networks in there and didn't visit any malicious sites. (At least as far as for the *JavaScript* vector that is.)

      • by Etcetera ( 14711 )

        Why was THIS modded down? This would actually work... to some degree, if you had all the ad networks in there and didn't visit any malicious sites. (At least as far as for the *JavaScript* vector that is.)

        That's basically ludicrous. You're better off disabling javascript and flash and leaving your hosts file untouched.

        Actually, if you wanted a way to make the web more secure? Make all the browsers default only to Javascript 1.1 or some other ancient version with just enough built-in support for DOM tweaking to maybe update the status ticker, and then ban all cross-site loading of js files that's not HTTPS.

      • by cm5oom ( 603394 )

        It was downvoted because it wouldn't work. A large amount of scripts come from the same domain as html and css files and images. Host based blocking does not give you the fine grained control you'd need to block one but not the others. But somebody will say use a host file to block ad servers and some other fine grained blocker for the domains that matter to which I reply why use two blockers to do the job of one? This is why he who should not be named is such a worhtless troll, his solution doesn't actuall

  • crazy (Score:4, Funny)

    by Anonymous Coward on Wednesday February 15, 2017 @07:28PM (#53877103)

    who would run anything on a machine with 22 CPUs? That's just ASKING to have your ASLR broken, right?

  • by K. S. Kyosuke ( 729550 ) on Wednesday February 15, 2017 @07:32PM (#53877121)
    So how exactly does this hurt me if the VM sandbox is secure? The paper seems to imply that you need other, much worse vulnerabilities to begin with to make use of this (beyond extracting information).
    • by Khyber ( 864651 )

      If you can read memory arbitrarily via this exploit, your sandbox is most certainly NOT secure. It's just another step to modifying memory contents after that and getting a full breakout.

      This exploit looks to be especially effective against cloud architecture as it currently stands.

      A whole lot of machines are inherently more compromised as a result of this, too. Because the idiot manufacturers do things like hard-locking a 64-bit system to 2GB of RAM (TOSHIBA and DELL and HP,) it makes ASLR essentially fuck

      • If you can read memory arbitrarily via this exploit

        I understand the exploit lets the attacker discover the randomized addresses, and hence have the knowledge of where vulnerable stuff is loaded in memory. I suspect the notion of read protection bypass was added by the journalist.

      • If you can read memory arbitrarily via this exploit, your sandbox is most certainly NOT secure.

        True, for a broader definition of the word, it isn't. What I had in mind is contained execution of code.

        It's just another step to modifying memory contents after that

        How? How to this help you to create a hole where there isn't one? And if there is one, shouldn't that be addressed first?

        • Comment removed based on user account deletion
          • So there's a way to read *arbitrary* data using the technique outlined here?
          • by bws111 ( 1216812 )

            ASLR is not memory protection. Breaking ASLR does not give read nor write access to any memory that the process did not already have. ASLR was introduced to help mitigate a bunch of buffer overflow attacks, by not having a 'predicatable' address that the attacker could branch to to execute his malicious code.

            So exactly HOW are you going to intercept that password, using a technique that would not be possible if ASLR was not broken?

    • So how exactly does this hurt me if the VM sandbox is secure? The paper seems to imply that you need other, much worse vulnerabilities to begin with to make use of this (beyond extracting information).

      Breaking out of a sandbox in a non ASLR virtual memory space is a solved problem. ASLR was developed to help prevent all the malware that worked that way.

      • Breaking out of a sandbox in a non ASLR virtual memory space is a solved problem.

        Could you direct me to instructions on how I do this in my Smalltalk VM, for example?

        • Breaking out of a sandbox in a non ASLR virtual memory space is a solved problem.

          Could you direct me to instructions on how I do this in my Smalltalk VM, for example?

          Nope. Not without a generously funded pen testing contract.
          You can find your own references on how to do it in a browser.

  • BeauHD (Score:5, Funny)

    by PopeRatzo ( 965947 ) on Wednesday February 15, 2017 @07:41PM (#53877193) Journal

    I thought Slashdot was supposed to be a tech site. What does Javascript attacks breaking ASLR on 22 microprocessor architectures have to do with tech?

  • When was it broken and who is breaking it in the wild?
    Security services? Federal law enforcement with lots of funding? Government workers? Private sector? Groups of very smart people?
    People with skills and a few powerful computers? People reusing code created by people with skills and one home computer?
    Any news on ip ranges and time zones?
  • In layman's terms, this means an AnC attack can break ASLR and allow the attacker to read portions of the computer's memory, which he could then use to launch more complex exploits and escalate access to the entire OS.

    Whaaaa....??

    • Whaaaa....??

      I feel the same way. Where's the damned car analogy?

      • by jeremyp ( 130771 ) on Thursday February 16, 2017 @06:12AM (#53878911) Homepage Journal

        You have got a car with Piers Morgan sitting in it. An attacker wants to head butt him in the face (trying to think of a backronym for AnC for this - I have Attacker Nuts... but I can't think of a word beginning with C that describes Piers Morgan) so, for his own protection, you choose where he sits in the car by a random process (Arsehole Seat Location Randomisation), so the chances are the attacker opens the wrong door.

        Anyway, it turns out that you can tell by how the car is riding on its springs where Piers Morgan is.

        • You have got a car with Piers Morgan sitting in it. An attacker wants to head butt him in the face (trying to think of a backronym for AnC for this - I have Attacker Nuts... but I can't think of a word beginning with C that describes Piers Morgan) so, for his own protection, you choose where he sits in the car by a random process (Arsehole Seat Location Randomisation), so the chances are the attacker opens the wrong door.

          Given what I've heard regarding Piers Morgan, I'd probably want to help the attacker identify the correct door!

  • by presidenteloco ( 659168 ) on Wednesday February 15, 2017 @08:52PM (#53877587)

    No, semi-seriously.

    The concept of a LISP machine was a computer which only executed one programming language, at least only one language in which non built-in code would execute.
    And that language was memory secure, in that it packaged memory use into high-level cells which referenced each other in a single standard way.

    There was no way that a process could "break out" and access something else's memory. A LISP program running in one process only understood and could access its own linked memory cells.

    This was enough programming freedom to program whatever you wanted, and the point is, the memory model was simple, uniform, and thereby secure.

    I'm not exactly saying return to LISP machines. I'm saying return to an architecture which includes a simple and secure memory access model, with no workarounds to the high-level memory cell access permitted. This could be enforced at the machine-language level, and/or by restricting allowed programming languages to inherently memory-secure ones.

    • Since then, Multiple JAVA architectures were invented. Hardware whose instruction set is binary compatible with JVM's byte code.

      I'd rather not. These things are a failure in the market for a reason.
    • by Anonymous Coward

      This is more of a side-channel attack. It looks like it works by timing how long it takes to access memory. Since cache misses are so expensive, it's easy to determine when you're encountered one, and so you can't easily guard against this.

      dom

    • Interesting. How would you implement shared memory in parallel processing computation(assuming that such type of machine would be multitaskable). Piping data around seems to be inefficient.
      I've trouble imagining how this consept would prevent me to break out of this sandboxish environment otherwise LISP functions _is_ chip instructions. If they are not there is theoretical possibility to change pointers. Can you elaborate on that idea?
    • If you cannot share memory between processes, you take a performance hit every time you need to share data. For some applications, this is a deal-breaker.

      If you can share memory in anyway, that sharing mechanism can be broken somehow.

      Pick your poison.

      (P.S. - The market made its choice long ago.)

      • Isn't it enough to be able to share memory between threads, rather than full processes, for most concurrent programming purposes?

        I stipulated that no programs except for those written in the single high-level language would be permitted to run on the machine. And that language would be designed to only allow secure, in-bounds memory access, via use of a high-level memory model such as LISP uses.

        So how would you write the exploit and get it to execute on the machine? You'd write it in the LISP equivalent lan

  • by PPH ( 736903 ) on Wednesday February 15, 2017 @08:53PM (#53877595)

    this component shares some of its cache with untrusted applications, including browsers

    Why does the MMU need to give user space apps access to its cache? Isn't the O/S, firmware and microcode supposed to provide a logical view of hardware like memory to prevent this sort of abuse?

    • AFAICT, the MMU cache isn't exposed, it's just using the same cache hardware on-chip, and you can time how long it takes to access certain things to figure out what's currently mapped into the cache (there are orders of magnitude difference in speeds for main memory vs cache, so even if you have no idea what's *in* cache, you can figure out where it's from). Also, breaking ASLR tells you *where* to read, but it shouldn't be able to tell you what's there without additional exploits being available.
    • Re:Why? (Score:5, Informative)

      by phantomfive ( 622387 ) on Thursday February 16, 2017 @01:01AM (#53878375) Journal
      It doesn't try to, it's a side-channel attack. So, ASLR pads elements with a random amount of free space, so a hacker doesn't know where to jump to. This attack figures out how big the free space is, by figuring out where the end of a cache line is. It figures out where the end of a cache line is by looking at the memory access times. So:

      x = a[n]; //runs in .5microseconds
      x = a[n+1]; //runs in 10 microseconds

      You know you hit a cache miss on the second access, and the end of a cache line is right between a[n] and a[n+1]. Based on the offset from where the cache would normally be, you can figure out how big the ASLR padding is. Once you know the padding size, you can know exactly which address to jump to to when you inject your shell code (ie, your compiled assembly exploit).

      There are other ways to defeat ASLR too, so I am not sure how useful this is, but the more techniques a hacker has, the better (from his perspective).
      • by PPH ( 736903 )

        x = a[n]; //runs in .5microseconds
        .
        .
        .

        OK. So you know where your data sits in the cache.

        you can know exactly which address to jump to

        What sort of shit-tier system are we running that allows us to jump to a location in data? Oh, yeah. JavaScript.

    • by mentil ( 1748130 )

      It doesn't. A high-precision timer is used to execute a timing attack to infer what the cache contains; major browsers nixed their built-in javascript high-precision timers, but they managed to cobble together their own (from allowed javascript functions, presumably), which incidentally reintroduces old timing attacks like RowHammer. Browsers can fudge javascript timing, but the larger problem would remain. Presumably, microcode updates could fix this.

  • Where I work we make security and authentication tools. Half the western world uses our products to authenticate themselves. Our products shouldn't use javascript. I would prefer that everyone in the world browse the internet with javascript turned off by default. If you go to a site you trust then turn it on. Unfortunately my own company forces people to use javascript because it makes sites look shiny and modern and pages are more responsive.(assuming you load 4MB of javascript bloat to a simple logi
  • by phantomfive ( 622387 ) on Wednesday February 15, 2017 @11:21PM (#53878143) Journal
    If the MMU is lesser known to you, then the ALU is going to blow your mind. Just don't look at MMX, it's ugly.
  • >, which is tasked with improving performance for cache management operations.

    Stopped reading right there. These guys have no idea what they're talking about.

  • Bad reporting (Score:5, Informative)

    by slew ( 2918 ) on Thursday February 16, 2017 @02:44AM (#53878577)

    This new Java script attack does *NOT* by itself compromise data, but simply allow a way to remotely extract the Address Space Layout Randomization that is currently employed by the OS. It does this by employing a javascript timer to measure page table walk times which are induced by executing javascript that accesses carefully selected offset in large objects (an earlier attempt to do this was frustrated by javascript implementations deliberately sabotaging the built-in high precision timer object). Once the specific ASLR pattern is determined for this specific boot of the kernel, other kernel vulnerabilities that involved direct access to aliased cache and/or memory locations that were mitigated by the kernel doing ASLR can now be modified to target the desired addresses on the target.

    It's like knowing how to make key to break into a specific car, but if you use it on the wrong car, it triggers the car alarm and not knowing what car the key it works on. If you magically had a way to map the VIN to the car key, you could make a key that works for that car and steal the car. The car dealers have this mapping, so they can make a key for you, but what someone came up with a way to figure out the VIN->KEY mapping over the internet?

  • So the MMU is a lesser known part of the CPU these days? *sigh*

  • In other words, we've created CPUs with instruction set architectures so sophisticated that they can't be made safe from exploitation.

    I may not understand the solution (if there is one), but I certainly admire the problem.

You know you've landed gear-up when it takes full power to taxi.

Working...