Hacker Bypasses Windows 7/8 Address Space Layout Randomization 208
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."
the only thing Microsoft and others can do is... (Score:5, Informative)
... 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.
OMG that is childishly simple (Score:2, Informative)
Fill up memory, then free some until enough is free to load the DLL.
Comment removed (Score:5, Informative)
Cool hack (Score:5, Informative)
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.
Re:the only thing Microsoft and others can do is.. (Score:4, Informative)
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.
Will not work on 64 bit (Score:2, Informative)
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.
Re:Other browsers and operating systems? (Score:5, Informative)
Is it possible to "rewrite the instruction pointer of the processor to a known heap address
where the shellcode resides quite deterministic" on, say, Firefox on Gnu/Linux [given that flash and java are disabled in the browser]?
This is an ASLR bypass technique, not an actual exploitable vulnerability by itself. The attacker still needs an exploitable memory corruotion vulnerability to start the attack. ASLR+DEP is designed to make it much harder for an attack to gain foothold in the face of such an attack.
An exploitable memory corruption bug could for instance be a buffer overflow or use-after-free bug in a jpeg or gif library. Such a bug allows a small window of opportunity for an attacker. However, with DEP he will have a hard time injecting actual executable code into the attacked process. Instead he will use a programming technique termed ROP (return oriented programming) where he will trampoline to code carefully chosen code fragments residing at known locations.
Think of a buffer overflow bug which allows the attacker to overwrite the return address of the vulnerable function. Instead of returning to the point where thebfunction was called, the instruction pointer will return to whatever the stack was overwritten with through the buffer overflow. The attacker *still* has not gained full control. But if he can overwrite with an address pointing to a piece of code which does all or part of what he needs he can use that. If it only does part of what he needs but ends with a RET, he can make sure that the stack above the original return address points to the Next piece of usable code.
This technique will Work in any process and on any operating system where the attacker is allowed relatively free access to allocate memory. Think browsers where JavaScript can be used to allocate/squeeze memory.
So yes, this is in no way Windows specific. It is interesting because at this point the Windows ASLR is pretty much state of the art. Only recently has OS X achieved randomization of the "dyld" - the OS libraries. Even a single library being loaded in a predictable location may be enough for the agtacker to squeeze through. Linux ASLR is weaker (not as random) and many Linux libraries are still loaded at perfectly predictable locations.
Re:OMG that is childishly simple (Score:4, Informative)
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.
Re:the only thing Microsoft and others can do is.. (Score:5, Informative)
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"
Re:Obvious? (Score:4, Informative)
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.
Re:TLDR (Score:3, Informative)
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:the only thing Microsoft and others can do is.. (Score:2, Informative)
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 programs will randomise the locations of libraries but not of the program itself), and there are still plenty of Linux distributions where it's *still* turned off in the default compiler (Debian and Ubuntu, certainly, and possibly others), but when it's implemented properly the attacker can't easily find the lookup table.
Also, I think you're possibly underestimating the difficulty of using the lookup table once you've found it. It's not like the attacker can just call GetProcAddress() or dlsym() in the target program (because otherwise they'd have a far easier way of gaining control), and it's not like they (usually) have a way of reading arbitrary bits of the program address space. It's not much use knowing where the lookup table is if you can't actually read it.