Forgot your password?
typodupeerror
Windows Security Technology

Hacker Bypasses Windows 7/8 Address Space Layout Randomization 208

Posted by Soulskill
from the just-a-matter-of-time dept.
hypnosec writes "Microsoft upped its security ante with Address Space Layout Randomization (ASLR) in Windows 7 and Windows 8, but it seems this mechanism to prevent hackers from jumping to a known memory location can be bypassed. A hacker has released a brilliant, yet simple trick to circumvent this protection. KingCope, a hacker who released several exploits targeting MySQL in December, has detailed a mechanism through which the ASLR of Windows 7, Windows 8 and probably other operating systems can be bypassed to load a DLL file with malicious instructions to a known address space."
This discussion has been archived. No new comments can be posted.

Hacker Bypasses Windows 7/8 Address Space Layout Randomization

Comments Filter:
  • Step One (Score:5, Funny)

    by Anonymous Coward on Friday January 25, 2013 @04:51PM (#42695907)

    Click on link in article...

  • by logicassasin (318009) on Friday January 25, 2013 @04:51PM (#42695911)

    ... delay the inevitable.

    Every new security feature they can dream up can and will be bypassed with enough time.All they can do is build it hard enough that it takes more time to crack.

    • by bigstrat2003 (1058574) on Friday January 25, 2013 @04:55PM (#42695953)
      I'm sure they're aware of that, as is anyone with a shred of knowledge about computer security (or hell, security in general). What is your point?
      • by Anonymous Coward on Friday January 25, 2013 @06:07PM (#42696641)

        Every new security feature they can dream up can and will be bypassed with enough time.All they can do is build it hard enough that it takes more time to crack

        I'm sure they're aware of that, as is anyone with a shred of knowledge about computer security (or hell, security in general). What is your point?

        Legend has it that Finnish field marshal Mannerheim was interviewed by a journalist after the Winter war. The journalist asked him if he had at any time doubted that the Finns would eventually be defeated by the Soviets. Apparently the old man sent the journalist a sharp look and then replied that just because the odds are against you it does not mean you have to make life easy for your attacker. Dunno fi that is true but if I was in computer security, that's what my outlook would be... come up with nasty defences, whey they are breached you ambush the bastards and then come up with a new line of even nastier defences.

        • by Nimey (114278)

          That's what the Japanese did on Iwo Jima. It's a well-known military and IT strategy called "defense in depth".

          • by rubycodez (864176) on Friday January 25, 2013 @08:28PM (#42697791)

            didn't work for the japanese, because no possibility of resupply, reinforcement, or retreat. Defeat thus assured. About 21,844 killed, 216 survivors taken prisoner. A horrible bloodbath and yes 6800 american soldiers killed, but it didn't "work"

            • by Nimey (114278)

              It was still better than the previous Japanese strategy of meeting us at the beaches and then banzai charges. Kuribayashi did quite well with the hand he was dealt.

              • by hairyfeet (841228)

                Ironically many of the strategies that the Japs used against us that look so stupid now actually worked against the Chinese but the Japanese military doctrine was so strict and unyielding that it just didn't take into account how vastly different the situation with the Chinese was compared to the Americans. The Banzai charge would work against the Chinese because they were armed with bolt action rifles that weren't in the best shape to start with so the Chinese couldn't hope to get more than a couple of poo

          • by Luckyo (1726890) on Friday January 25, 2013 @09:20PM (#42698025)

            Japanese on Iwo Jima was "desperate defense with no hope of victory".

            Finnish was "pre-planned defense in order to make enemy bleed so hard, that even Stalin would decide that gains aren't worth the cost".
            It succeeded twice with quite possibly the single most insane-looking numbers in history. It was crazy enough to warrant wikipedia page screenshot becoming an internet meme:
            http://www.google.com/imgres?imgurl=http://data.whicdn.com/images/18990146/finland-be-afraid-be-very-afraid_thumb.jpg&imgrefurl=http://weheartit.com/tag/soviet%2520russia&h=200&w=240&sz=11&tbnid=e8G9SZNgTBMY-M:&tbnh=87&tbnw=104&zoom=1&usg=__Tk2w1zc2NxuOzEu4OclPzzBZzVc=&sa=X&ei=RjoDUfekBYbKtAaMuYCwCQ&ved=0CCEQ9QEwAw [google.com]

            This success was repeated in 1944 where Finns faced the single biggest offensive in the entire WW2 war European theatre. Soviets focused 20 artillery pieces per every kilometer of the front line. They could literally dig people out of trenches with this much artillery. In the end, finns held out and even pushed back in spite of being completely outnumbered and outgunned. Stalin remembered the lesson from Winter War and signed a peace treaty with Finland allowing it to stay independent again. It ended up going in history as the only country mentioned in Molotov-Ribbentrop that didn't get conquered by either Germany or USSR.

            The main difference between these strategies is that Japanese viewed their empire as something holy and to be defended to the death, to the point where survivors should commit suicide if they failed. Finns viewed their country as something of theirs, and to be defended for as long as it remains defensible with as little losses as possible. Key difference was that finnish commanders valued lives of their soldiers very highly for the times. Japanese commanders treated their soldiers as completely disposable pawns. Difference could be explained by the fact that Japan is one of the most populated regions on the planet, while Finland is one of the least populated ones.

            It's the advantage of not being a huge country with long and proud history. You learn that to stand between the giants and survive, you need to show humility to the giants in most things, but also show that when needed, you can sting them so painfully, that any potential attempts of capture will not be worth it. And most of all you learn that when you're losing, minimize your losses so you can fight another day.

            • by microbox (704317)

              Japanese commanders treated their soldiers as completely disposable pawns.

              If you watch the very excellent world at war series [wikipedia.org], you will note an interview with one of those japanese commanders where he says that he was overwhelmed with volunteers for suicide missions. Different culture, different times.

              On a side note, there will never be a better WWII documentary, because too many of the key players are dead now. The World At War series (26 episodes) has plenty of interviews with people who were actually there -- although recent declassification of soviet materials has changed

    • by icebike (68054) on Friday January 25, 2013 @05:15PM (#42696169)

      True, but you have to consider that ASLR was never intended as an unbreakable security feature. It was always just an impediment to an easy exploit of jumping to a fixed address. There are common tricks published [stackoverflow.com] for getting around ASLR to some degree.

      • Re: (Score:3, Interesting)

        by BitZtream (692029)

        True, but you have to consider that ASLR was never intended as an unbreakable security feature. It was always just an impediment to an easy exploit of jumping to a fixed address. There are common tricks published [stackoverflow.com] for getting around ASLR to some degree.

        Anyone who truly understands how computers work and specifically how ASLR does what it does should be fully aware that ASLR only stops absolutely stupid hacks. All important addresses can be looked up. They have to be looked up to be useful. If nothing can lookup an important address, nothing can really do anything to it, making it not real useful for computing in general, let alone hacking.

        To get around ASLR all you have to do is consult ... the built in lookup table which is at ... A FIXED ADDRESS as i

        • by r00t (33219) on Saturday January 26, 2013 @03:41AM (#42699289) Journal

          You're right that it boils down to just looking up the address, but see, this is a chicken-and-egg problem. You're wanting to determine addresses so you can run code, but you must run code in order to look up addresses!

          You might as well say that it is easy to get a dinosaur and a dinosaur egg. To get the dinosaur, just wait for a dinosaur egg to hatch. To get the dinosaur egg, just wait for a dinosaur to lay one. Problem solved, right???

        • Re: (Score:2, Informative)

          by Anonymous Coward

          Anyone who truly understands how computers work and specifically how ASLR does what it does should be fully aware that ASLR only stops absolutely stupid hacks. All important addresses can be looked up. They have to be looked up to be useful. If nothing can lookup an important address, nothing can really do anything to it, making it not real useful for computing in general, let alone hacking.

          To get around ASLR all you have to do is consult ... the built in lookup table which is at ... A FIXED ADDRESS as it has to be able to be found for everything to work.

          No, the lookup table isn't at a fixed address. That is, in fact, the whole bloody point. The lookup table (technically the PLT, at least for ELF binaries) is at a fixed offset relative to the main binary, so if you can figure out where the main program is in memory you can find it very easily, but the point of ASLR is that it's non-trivial for the attacker to find the binary, and so they can't find the lookup table.

          Now, admittedly, programs have to actually be compiled to use ASLR for this to work (older

    • by hairyfeet (841228)

      Oh its worse than that now, in the old days you'd have one or two high level bug writers that could dig up exploits for major components like this, then there were the script kiddies that were just looking at what the last set of patches were plugging then writing a bug based around those patches.

      But thanks to virus kits and a thriving black market for bugs what we have now is a variation of the smart cow problem [wikipedia.org] in that by the time most companies find out there is a new bug targeting a critical subsystem

  • by Anonymous Coward

    Fill up memory, then free some until enough is free to load the DLL.

    • by gnasher719 (869701) on Friday January 25, 2013 @07:16PM (#42697219)

      Fill up memory, then free some until enough is free to load the DLL.

      Which works fine with a 32 bit operating system. With 64 bit, filling up memory looks like a hard job to me.

      • by mhotchin (791085)

        On 64 bit, I wonder if allocating (reserving) the VM space, but not allocating memory for it, would do the trick. Harder (impossible?) to do from javascript though.

      • by BitZtream (692029)

        VirtualAlloc's without requiring a backing store work just fine for consuming enough of the 64 bit virtual backing store that it doesn't matter.

        Asking for space but telling the OS you don't need it right NOW will get you an address space with no memory used until you cause a page fault by accessing it causing a page of real memory to actually be attached to it. Until that point, its just an entry in the page table, to which its easy to fill up, your computer does it every boot.

        • by jhol13 (1087781)

          All this can be trivially stopped by ulimit. If a javascript can allocate 4 gigs of memory it is effectively a DoS. I would never let some web script allocate more than a fraction of physical memory.
          Besides, there is absolutely no reason for a DLL to be put into same address where allocation heap resides.

        • Yep. I toyed a bit over Xmas with fixed location dynamic arrays. The problem I was trying to solve was that dynamic arrays keep moving around their data as they grow, and multiple threads accessing those arrays can clobber each other. By allocating 32 bits of address space for each dynamic array, I avoid having to relocate it as it grows. It worked OK, but unfortunately, the page table memory is not free. At startup, my code allocated many of megabytes of page table data. It also took several seconds

        • by Rockoon (1252108)
          From what I understand, the WIN64 address space is 2^42, and a WIN64 page is still 2^12, which means a total of 2^30 possible virtual page addresses.. a binary billion.

          With 8 byte page table entries thats 8GB of memory just for the page table.

          So I'm thinking its not actually possible to fill up the page table in systems with 8GB or less memory, and systems with 12GB of memory would probably be thrashing extremely hard (writing multiple gigabytes of data is a slow process, even on high performance SSD's)
    • by mmell (832646)
      But the way ASLR is (supposed) to work . . . theoretically, it should not be possible to know what blocks of memory are used, which ones are still free, which ones you are freeing up when you deallocate memory. I'm assuming Java gets a relative memory pointer when it allocates memory and not an absolute one.

      If Java gets an absolute address then, yes - this is childishly simple (and that seems to be the behavior in this case). If that's so, this guy is keeping the best under his hat, because I can think o

      • by Rockoon (1252108)
        Its not possible to hide the absolute address, so nobody uses relative addressing in 32-bit because its less efficient, and in 64-bit while relative addressing no longer has a performance penalty its still impossible to hide the absolute address.
  • Obvious? (Score:4, Interesting)

    by Todd Knarr (15451) on Friday January 25, 2013 @04:57PM (#42695967) Homepage

    And this exploit wasn't obvious from the start? When the heap and dynamically-loaded code share the same address space, this vulnerability always exists. We knew this 30 years ago. It took someone this long to apply it?

    • by icebike (68054)

      I wonder if this would be reliable in a heavily used machine with lots of processes vying for memory. There may be demands for memory blocks in the queue which were waiting longer than your request which might get serviced first.

      • Re:Obvious? (Score:4, Informative)

        by Todd Knarr (15451) on Friday January 25, 2013 @10:21PM (#42698329) Homepage

        Processes would be irrelevant, since each one has it's own address space (the exploit works on the process level, not down on physical memory). And with NOP slides and other tricks, you don't need to pin down the location to the byte. Allocate one large block that'll be forced into the end of memory (start too large and work down until it succeeds, it'll have been allocated at the end of the heap because that's the only place that has a single contiguous block big enough open), allocate smaller blocks until the allocation fails (you've now filled up the heap), then resize your big block down enough to open up a hole for the DLL (it'll be loaded immediately after your big block since that's where the hole was opened up). The only real trick is chopping up the low portion of the heap and leaving enough small blocks there that most normal allocation will be happening below your big block while the only hole big enough for the DLL is above the big block, and it's not like that's all that challenging a programming problem.

        And the amusing thing is that the x86 architecture allows you to make this sort of exploit physically impossible (at least without cracking ring 0 first). Separate code, heap and stack and place the heap and stack in non-executable segments, and any attempt to try this kind of thing just results in the kernel getting a memory access exception and terminating the offending process.

  • TLDR (Score:5, Informative)

    by YodasEvilTwin (2014446) on Friday January 25, 2013 @04:57PM (#42695969) Homepage
    Fill memory until only enough space is left for loading whatever it is you're trying to load. Obviously the location is predictable since there's only one spot for it.
    • by Kaenneth (82978)

      If an attacker has enough access to fill all the address space of a 64 bit process, it sounds like they are already in too much control.

      "It rather involved being on the other side of this airtight hatchway."

      • by asmkm22 (1902712)

        This appears to be a 32-bit exploit, at least as tested.

        • by Shoten (260439)

          This appears to be a 32-bit exploit, at least as tested.

          That depends on what you mean by "32-bit exploit." He's doing it as 32-bit code because then you have a LOT less memory to fill up. Even better, you have a predictable amount of memory to fill. It affects operating systems which are 64-bit; he's not doing it in a way that makes those OS versions safe, but for his own convenience of exploitation. There's another added benefit as well...not only is it easier to fill up the RAM of a 32-bit memory space, but in a 64-bit environment you won't be as likely to

          • There's another added benefit as well...not only is it easier to fill up the RAM of a 32-bit memory space, but in a 64-bit environment you won't be as likely to slog the machine down overall while you do so.

            Quite the opposite. With 64 bit, the logical address space is many orders of magnitude bigger than available RAM. So you end up thrashing your virtual memory quite soon. However, the logical address space is still orders of magnitude bigger than your swapspace (4 TB if we are generous), so it's quite impossible to fill the 64 bit address space.

            • by Shoten (260439)

              I think you've confused potential address space with actual available RAM. While you're right that there will be an impact on performance from filling up a 32-bit address space in the larger confines of a 64-bit operating system, you'll cause an even greater impact if you fill up all the actual available RAM by running the exploit in 64-bit context. And it's not about address space; the point is not to fill the address space that is potential, but the actual available RAM, because that's the point where y

              • Re: (Score:3, Informative)

                by BZ (40346)

                Actually, the address space is in fact key. The goal is to load a known DLL at a known address in the process address space, not a known address in physical RAM, because process address space is what you can see in the code that you will then try to run that will try to call into the DLL.

                So in a 64-bit process, this technique is pretty hard to pull off, since it does in fact rely on address space exhaustion.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Not only that but the point of ASLR is to randomly locate system DLLs, not some evil hacker code. This does nothing to break the intended use of ASLR.

      • It is very uncommon to see 64-bit web browsers, as most plugins only come in 32-bit flavors. So running a 64-bit Windows won't matter for 99.99% of users. Only IE offers a 64-bit version, at least theirs is the easiest to find and use. Firefox might offer one I think? But it won't be the default download. Chrome does not yet offer one for Windows.
        • by PRMan (959735)
          Firefox just quit their 64-bit version and then re-instituted it based on the collective howls of nerds everywhere.
          • "lynx" is also 64-bit, and works very well for visually impaired people who need robust text-speech. If your website does not work with lynx, it's probably too gizmo filled for ordinary use, anyway.

        • Only IE offers a 64-bit version

          Whoa, that's wrong. I have been using 64-bit Opera for months.

        • by cheekyboy (598084)

          its not hard to have a 64bit app running, with another 32bit process having its window open inside the 64bit bit apps main window.

          The 32bit plugin can commuincate to the 64bit browser by usual ipc/tcp/windows msgs way.

          Sure its a bit of effort, but stop being lazy, or shall we say, the 32bit plugin people, stop being lazy! make a 64bit ver.

      • by BitZtream (692029)

        So you think any application on your computer has too much access?

    • There's also a really easy solution to this: Change the loader so that if there isn't enough space to perform the ASLR then the load fails. You have to handle the loader failing when you're down to the end of your memory space anyway. Suddenly you are back to not knowing where to jump to again.

    • by jhol13 (1087781)

      Why is a web loaded javascript code allowed to fill the entire memory in the first place? Isn't it effectively a DoS, as the machine will swap for the next quite a few minutes?

  • Cool hack (Score:5, Informative)

    by sl4shd0rk (755837) on Friday January 25, 2013 @05:03PM (#42696037)

    So basically use javascript to allocate all available memory. Once you get the allocation exception, begin freeing small chunks. After each free, try loading an Active X DLL (target DLL exploit). As soon as you have freed enough blocks, the DLL will load into the space you freed. Essentially bypassing any ASLR -- there is nowhere to randomize too except the freed memory.

    • by asmkm22 (1902712)

      This doesn't seem to be a fundamental problem with ASLR, at least. Things could be patched to prevent something from filling up memory like that, I assume.

  • The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.

    Unfortunately many browsers still run 32bit even on 64bit systems because of plugin compatibility. Time to move to 64 bit browser processes.

    Note also that this attack is only feasible against browsers. Like other ASLR bypasses it will not Work against e.g. Outlook or Word where the attacker has very limited ability to control memory allocation.

    • by Carnildo (712617) on Friday January 25, 2013 @05:28PM (#42696271) Homepage Journal

      The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.

      Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.

      • The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.

        Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.

        True. Butbthe OS will not commit more memory than it is *actually* able to assign to the process at some point. Once you allocated the memory it is the process to use. It may not be backed by physical or virtual memory (paging file) yet, but the OS must guarantee that memory *can* be accessed once it has committed to it.

        The point still stands. There's a reason the article specifically limits the PoC to 32bit processes.

      • by cnettel (836611)

        The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.

        Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.

        True, but just the data structures for the OS heap could also become a serious burden when we start approaching actually filling the address space. On the other hand, x64 CPUs cannot handle fully arbitrary addresses, so it's all a complicated story. Suffice to say that any method using Javascript or most other "simple" ways to trigger memory allocation will also trigger memory writes into the newly allocated pages. You have to be rather careful not to write or init allocated pages in most languages and envi

    • by Jahava (946858)

      The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.

      Unfortunately many browsers still run 32bit even on 64bit systems because of plugin compatibility. Time to move to 64 bit browser processes.

      Note also that this attack is only feasible against browsers. Like other ASLR bypasses it will not Work against e.g. Outlook or Word where the attacker has very limited ability to control memory allocation.

      It's worth mentioning that the critical component here is using client-executed trusted/sandboxed code (in this case, JavaScript) to exhaust the memory space. The code must be able to allocate memory, and it must be able to identify the virtual address of the memory that it allocated, else when it begins opening a hole for ASLR determinism, the shellcode won't know where to target.

      Any client-side language that can allocate arbitrary memory and identify the allocated address should be able to be used in this

    • by rsborg (111459)

      Unfortunately many browsers still run 32bit even on 64bit systems because of plugin compatibility. Time to move to 64 bit browser processes.

      Notably, Google Chrome, as well as Firefox are 32-bit. Amusingly in Win8 RT, since IE is the only legitimate browser for Metro, the new tablets are resistant to this attack. It's sad that big-time browsers don't have 64 bit builds, and that you have to roll your own (Firefox - I use Waterfox) or just suffer under IA32 legacy.

  • The point with ASLR is for the good process to not be infiltrated by a bad one. I dont see the problem of loading a dll in a known memory location, unless you apply that to a dll of the good application, without it detecting that.

    But when you arrive at that point of being able to do that, what's circumventing ASLR good for?

    • The point with ASLR is for the good process to not be infiltrated by a bad one. I dont see the problem of loading a dll in a known memory location, unless you apply that to a dll of the good application, without it detecting that.

      But when you arrive at that point of being able to do that, what's circumventing ASLR good for?

      You are correct that ASLR it a *mitigation*; not a failsafe protection in itself. Nor is this weakness and exploitable vulnerability *in itself*. An attacker still needs an actual exploitable memory corruption bug. But when one is found, the technique referred to as ROP can be used to bypass DEP/NX protections to gain foothold. The answer to ROP (where the attacker uses fragments of executable code loaded in known locations) is ASLR. This technique squeezes memory to take the "randomization" away from ASLR

  • by hduff (570443)

    Or at least by Windows 10.

  • Are we ever going to fix the real issue? You generally use one to start horking the stack and then get the CPU to jump to some address. Then these protections come into play.

    I get the feeling people have just given up versus trying to change compilers and hardware to protect the stack. I should be able to keep writing into an unprotected char array and never come close to some instruction pointer shouldn't I. Is it too much to demand?

  • Address space randomization is a form of security through obscurity. It's also an admission that your system security really sucks. The concept is that the code is full of exploitable buffer overflows, but address space randomization will make it harder for exploits to patch the right target area. So low-level exploits tend to crash the system, or at least just mess it up, rather than getting their code executed.

    There are now "address spraying" attacks which counter address space randomization, so this is already an obsolete defensive measure.

    • by flonker (526111)

      security through obscurity

      I do not think that means what you think it means.

      "Security through obscurity" is being deliberately insecure and relying on other people not knowing about the insecurity as your defense.

      Something like this relies on the fact that choosing a random address is much easier than guessing a random address that was previously chosen. This flaw results in forcing the victim to choose a non-random address when they intend to choose a random one. And "address spraying" works by increasing the size of the target t

    • by bloodhawk (813939)
      It is not security through obscurity at all. It is Defence in Depth, You should ALWAYS assume all code has bugs and a portion of those bugs are potentially security bugs. ASLR is an additional mitigation (Defence in Depth) for when the inevitable human error next pops up to make it harder to exploit.
  • From TFA: The PoC makes use of the following vulnerability and therefore for testing the PoC the patch must not be installed. MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability This vulnerability is identified as CVE-2012-4969. So it's already preventable. (Yes, yes, patching is a bitch, doesn't happen, etc etc.) And also, it's already detected: Please note that Windows Defender detects the Win8 PoC as being an exploit and blocks execution. Yes, it's an interesting PoC, but i
  • > A hacker has releasedÂa brilliant, yet simple trick to
    > circumvent this protection

    Beating up the guy after he logs in?

The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov

Working...