Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Operating Systems Security Intel OS X Privacy Software Windows News Hardware Linux Technology

Researchers Bypass ASLR Protection On Intel Haswell CPUs ( 72

An anonymous reader writes: "A team of scientists from two U.S. universities has devised a method of bypassing ASLR (Address Space Layout Randomization) protection by taking advantage of the BTB (Branch Target Buffer), a component included in many modern CPU architectures, including Intel Haswell CPUs, the processor they used for tests in their research," reports Softpedia. The researchers discovered that by blasting the BTB with random data, they could run a successful collision attack that reveals the memory locations where apps execute code in the computer's memory -- the very thing that ASLR protection was meant to hide. While during their tests they used a Linux PC with a Intel Haswell CPU, researchers said the attack can be ported to other CPU architectures and operating systems where ASLR is deployed, such as Android, iOS, macOS, and Windows. From start to finish, the collision attack only takes 60 milliseconds, meaning it can be embedded with malware or any other digital forensics tool and run without needing hours of intense CPU processing. You can read the research paper, titled "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR," here.
This discussion has been archived. No new comments can be posted.

Researchers Bypass ASLR Protection On Intel Haswell CPUs

Comments Filter:
  • ... was it ever worth it?

    • no. locks keep honest people honest. when you decide the user cant be trusted, all pretense of keeping honesty in the mix evaporates.

      the responsibility for a system lays at the foot of the user. nobody else.

      • by Anonymous Coward on Thursday October 20, 2016 @12:14AM (#53112769)

        Eh, it's still worth it. I think that these other layers shouldn't be discussed in the same manner as a "lock" type layer though. These are more properly "mitigations", things that are supposed to help some of the time, increase time to entry, increase the burden of resources required for an attack like this. There's merit in there.

      • The user is only part of the problem it is the admin that you have to worry about. or more specifically the user who thinks they are an admin.

        Would you jump into the pilot's seat of a helicopter and steal it, just because you saw a video of a helicopter flying?

        That is how the average user admin's their computer with the predictable result.

        Computers are massively complicated machines, with millions of interconnected parts and most don't understand how they connect together and have issues. So you have to d

    • by AHuxley ( 892839 )
      It sold as protection to big brands for a generation. So it was worth it to a few brands shareholders.
    • by bytesex ( 112972 )

      Of course it does. ASLR does not just protect you from local exploits, but also from remote ones.

    • Remote exploit (Score:5, Informative)

      by DrYak ( 748999 ) on Thursday October 20, 2016 @08:17AM (#53114013) Homepage

      TL;DR: because of this bypass ASLR cannot prevent local privilege escalation. but ASLR can still prevent remote access.

      The point of ASLR is that it's not easy to determine where the functions are located in memory.

      So, if there's an exploit where you can force code to jump at some specific point in memory, you cannot use this exploit to call the function you want because you don't know where they are.

      (e.g.: stack smash. Overrun some temporary buffer that is stored on the stack buffer, up to the point where you can overload the return address. So once a function finished, it's doesn't jump back to the caller [it doesn't return] it jumps instead to the address you've overwritten [it jumps to the next function you want to abuse as part of you exploit] )

      2 possible situations:

      - You've already managed to get (user-level) shell acces (or at least run any payload of your choosing). You want to escalate privileges up to root. You know of a bug in some kernel piece of code that you can try to exploit. ASLR would prevent you from doing it because you don't know where the piece of code is exactly in kernel memory space. So you run the bypass proposed by the researcher and you obtain a list of where is what.
      Now you can run your exploit, and gain root.

      - You're outside the machine. You want to get remote access. You know a bug in some code (be it kernel or userspace) that could be exploited. But you need to jump into specific function whose precise location in memory you don't know because of ASLR.

      So ASLR won't block local privilege escalation anymore (because when you have local access you could defeat ASLR's randomisations)
      But ASLR will still block remote access (without local access, you can't get a map of all ASLR-ised functions you need to inject in your remote exploit).

      • Most attacks these days are a sequence of memory safety violation followed by memory disclosure followed by arbitrary code execution. ASLR is meant to make the memory disclosure part harder, but there are now half a dozen known attack techniques that allow ASLR to be bypassed. Off the shelf attack toolkits will include these mechanisms, so it's a mistake to assume that an attacker won't be able to bypass it. It increases the barrier to entry from script kiddie with 5-year-old toys to script kiddie with n
  • by Anonymous Coward on Thursday October 20, 2016 @12:13AM (#53112757)

    The Enhanced Mitigation Experience Toolkit, which is offered by Microsoft for the Windows operating system, provides a software implementation of Address Space Layout Randomization (ASLR), in addition to what is or is not provided in hardware, but that's not all. The software also offers Data Execution Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP), Certificate Trust (Pinning) and blocks untrusted fonts. Granted, this is an optional add-on for Windows that requires some expertise on the part of the user to make the best use of, but in knowledgeable hands tools like these can be used to further enhance the security of the system by making it that much harder for attackers to successfully inject executable code into the address space of privileged processes.

    • by Anonymous Coward

      It is an exploit of the CPU's cache, a cache collision attack, if your data's location is referenced in the "Branch Target Buffer" cache then it is vulnerable, if you can find the location table random locations are meaningless. As such this threatens all software implementations Windows, Linux, whoever does it they are all vulnerable unless they find and implement a way of avoiding the collision or removing themselves from the cache (at a performance cost).

    • by DarkOx ( 621550 )

      EMET on Windows is a great tool! What a name though, only the Microsoft marketing droids could invent that one. "Mitigation Experience" never in a million years would it have occurred to me I should be concerned about my experience mitigating something. Thanks marketers!

  • Man... oh man.... (Score:5, Interesting)

    by alexborges ( 313924 ) on Thursday October 20, 2016 @12:16AM (#53112773)

    I've been a true blue IT pro foss loonix guy for most of the last 16 years. And every year. Nay. Every 6-10 months some hardware designed to "thwart" crackers, and other crypto attackers goes the way of the dodo.

    I think the industry looks at security the wrong way and the lulzsec guys weren't wrong in that ideological rant they made. You can't predict the unpredictable. Firewalls aren't a wall in any meaningful sense. "Software defined" networks are just a catchphrase for networking complex things in a dynamic manner. Intrusion Prevention Systems do not prevent. Hell, if you let your cisco guy deploy it, it wont even log a thing and when it dies you will have no idea why.

    Bollocks, Shenanigans and costly Stupidity (don't get me started on "hardware routers" or "storage networks"). This is what I have found in my years in the battlefields, young grasshoppers. And a deeply felt wish that I had chosen archeology instead.

    • by moxsam ( 917470 )
      The grass is always greener...

      I wonder how many archeologists with bad pay wish they had become an IT professional instead.
    • by AHuxley ( 892839 )
      If the NSA says the big US brands they work with are safe, buy them and enjoy the US industry standards.
      Stop making networks interesting. Put PR on the internet when the project is done and ready for sale.
      Until then keep everything secret.
      Doing code work for years on internet facing networks on hardware designed for easy police and security service access is just a big risk.
      Too many nations, their staff, ex staff, cults and smart people have the keys or know of the trap doors and backdoors.
    • You should read up on the AS/400 Architecture. So different from the PC word and much more logical, no such thing as device drivers and buffer overflows can't happen.

  • Imagine the infinite ways of using other people's computers without their explicit permission.

  • I will guarantee can't be hacked electronically and will sell you one.

  • by kungfuj35u5 ( 1331351 ) on Thursday October 20, 2016 @01:02AM (#53112929)

    removing the BTB entirely. I've seen libraries rip out faster routines or add some nondeterminism to the latency just so that it could mask such a "hot cache" vulnerability. It seems a bit backward to rip out a performance enhancing capability in the architecture just because of ASLR bypass.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Or just make it part of the context of each process that has to be switched out...

      Obviously the problem is making it a global resource.

    • by ameline ( 771895 )

      There are a number of alternatives -- flushing the BTB on ring switch seems a reasonable starting point. It should eliminate most privilege escalations.
      Making the address randomization affect bits outside the range seen by the BTB indexing scheme would also make the attack much more difficult. This would require some non-trivial OS kernel changes

      The BTBs themselves can be multi-level and pretty large -- they could form part of a process context, but they'd add several kbytes to it. There is no hardware supp

  • by Anonymous Coward

    ...again. Provided this screwup is on Broadwell and Skylake, which is not a far fetched possibility *at all*.

    Intel SGX is all about running secret code on untrusted processors, and this kind of side-channel allows one to probe inside the SGX container. One of the useful (read: non-DRM-crap) uses for SGX would be to implement secured data+code areas to run crypto-sensitive portions of SSH, GnuPG, etc. Unfortunately, branch probing is good for a lot more than defeating ALSR, you can actually, when one is

  • You will never have perfect security. There is no such thing. All you can do is put up sufficient roadblocks that a miscreant will give up before they are successful.

    And all the security measures in the world arn't going to make a lick of difference if the user opens the door and waves the bad guy in.

  • That looks like a chicken and egg problem:
    • You want to execute some code using a buffer overflow.
    • And to perform the buffer overflow under ASLR, you need to execute some code to break it.

A bug in the hand is better than one as yet undetected.