Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hacker Bypasses Windows 7/8 Address Space Layout Randomization

Soulskill posted about a year and a half ago | from the just-a-matter-of-time dept.

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

Sorry! There are no comments related to the filter you selected.

Step One (5, Funny)

Anonymous Coward | about a year and a half ago | (#42695907)

Click on link in article...

the only thing Microsoft and others can do is... (4, Informative)

logicassasin (318009) | about a year and a half ago | (#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.

Re:the only thing Microsoft and others can do is.. (5, Insightful)

bigstrat2003 (1058574) | about a year and a half ago | (#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?

Re:the only thing Microsoft and others can do is.. (0)

Anonymous Coward | about a year and a half ago | (#42696587)

just another variant of the "everybody is as shitty as M$" meme.

Re:the only thing Microsoft and others can do is.. (5, Interesting)

Anonymous Coward | about a year and a half ago | (#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.

Re:the only thing Microsoft and others can do is.. (1)

Nimey (114278) | about a year and a half ago | (#42697103)

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

Re:the only thing Microsoft and others can do is.. (3, Informative)

icebike (68054) | about a year and a half ago | (#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:the only thing Microsoft and others can do is.. (0)

BoRegardless (721219) | about a year and a half ago | (#42696217)

So are only safe if we run an OS on an isolated partition which has nothing but a web browser and the other partitions are automatically unmounted while the web browser OS is working?

Then whatever we want to take back to other partitions upon reboot (hope you have your SSD) has been scanned thoroughly and copied to an empty partition before that reboot?

The options to remain safe don't seem to be coming from Microsloth from its Microseneian era world of the DOS age of computers.

And these are the guys who think their OS is not only the best but worth the mega-premium versus Apple's OS price or Linux.

Re:the only thing Microsoft and others can do is.. (1)

Smoky D. Bear (734215) | about a year and a half ago | (#42696499)

The isolated OS for a web browser works. All of my web browsing is done through VMs with persistent disks. Even on my Linux machines.

Re:the only thing Microsoft and others can do is.. (1)

MacGyver2210 (1053110) | about a year and a half ago | (#42696651)

Just use VMs...

No need to do an entire partition/separate OS thing the hard way these days. Especially not just for web browsing.

Re:the only thing Microsoft and others can do is.. (1)

Anonymous Coward | about a year and a half ago | (#42696729)

Microsoft released ASLR slightly before Apple, and when Apple did release it their implementation was incomplete. I also seem to recall that microsoft was possibly the first or close to the first to sandbox their browser. The Linux kernel had ASLR earlier than both but lets be honest - theres a difference between bringing a technology out and releasing it to 1% of computers via the internet (Linux), and shipping it in a consumer OS (Microsoft)

As for making up names about Microsoft - well that really is from the DOS age.

Re:the only thing Microsoft and others can do is.. (2)

fahrbot-bot (874524) | about a year and a half ago | (#42696775)

So are only safe if we run an OS on an isolated partition which has nothing but a web browser and the other partitions are automatically unmounted while the web browser OS is working?

Actually, we are only safe while the system is powered off, disconnected from all cabling and still in the box it came in. Trust me. After dealing with security weenies and various system lock-down methodologies for many, many years, a truly "secure" system (to their satisfaction, anyway) is unusable and you might as well not even bother to unpack it.

Re:the only thing Microsoft and others can do is.. (1)

ozmanjusri (601766) | about a year and a half ago | (#42697391)

So are only safe if we run an OS on an isolated partition which has nothing but a web browser and the other partitions are automatically unmounted while the web browser OS is working?

OS on read-only media, sessions in disposable VMs.

Re:the only thing Microsoft and others can do is.. (0)

Anonymous Coward | about a year and a half ago | (#42696845)

Well, ASLR is the wrong answer in the first place. It's security through obscurity, which means it's adding obscurity, not security.

OMG that is childishly simple (2, Informative)

Anonymous Coward | about a year and a half ago | (#42695963)

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

Re:OMG that is childishly simple (3, Informative)

gnasher719 (869701) | about a year and a half ago | (#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.

Re:OMG that is childishly simple (1)

mhotchin (791085) | about a year and a half ago | (#42697595)

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.

Re:OMG that is childishly simple (-1)

Anonymous Coward | about a year and a half ago | (#42697649)

hello dumbass, just because you're on a 64-bit system doesn't mean you have 64 bits of address space available to fill .. most computers especially desktops still don't have that much ram

Re:OMG that is childishly simple (1)

mmell (832646) | about a year and a half ago | (#42697289)

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 of a few ways to speed the process and reduce the risk of the target machine crashing due to lack of available memory.

Obvious? (3, Interesting)

Todd Knarr (15451) | about a year and a half ago | (#42695967)

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?

Re:Obvious? (1)

icebike (68054) | about a year and a half ago | (#42696201)

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? (0)

Anonymous Coward | about a year and a half ago | (#42697329)

heavily used machine with lots of processes vying for memory.

You mean in 2003 ? Cause it's 2013 now and CPUs are so powerful while software is so poorly written that the most loaded machines average on 80% cpu usage throughout the day.

Just opening a thread (let alone a process) spikes the cpu (both windows and linux). A few cycles later it flattens while the RAM catches up with the disk reads. It's also true on SSDs...

Re:Obvious? (3, Interesting)

icebike (68054) | about a year and a half ago | (#42697525)

True, but that just shows how often demands for memory can happen in a modern multi-core machine.
Microsoft didn't implement ASLR until 2007 (Vista).

With so much multitasking going on under the processors of that time and today, it would suggest that any attempt to saturate memory would inconvience many tasks, many of whom would have allocation requests pending, probably for smaller chunks than your rogue task would require. These would stack up while your were saturating memory, and be serviced upon first, as soon as you released your block. There is no way you can do a system call tor free-memory AND follow it with DLL load command without yielding some time slots on the processors and memory allocation routines. The busier the machine the more likely this is to fail because allocation requests are always in flight.

TLDR (5, Informative)

YodasEvilTwin (2014446) | about a year and a half ago | (#42695969)

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.

Re:TLDR (1)

Kaenneth (82978) | about a year and a half ago | (#42696083)

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

Re:TLDR (2)

asmkm22 (1902712) | about a year and a half ago | (#42696149)

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

Re:TLDR (2)

Shoten (260439) | about a year and a half ago | (#42696959)

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 slog the machine down overall while you do so.

Re:TLDR (2)

gnasher719 (869701) | about a year and a half ago | (#42697247)

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.

Re:TLDR (2, Insightful)

Anonymous Coward | about a year and a half ago | (#42696177)

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.

Re:TLDR (0)

Anonymous Coward | about a year and a half ago | (#42696517)

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.

The exploit describe in the article causes a system DLL to be located in a predictable location, so it does break the intended use of ASLR.

Re:TLDR (0)

Anonymous Coward | about a year and a half ago | (#42696695)

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.

The exploit describe in the article causes a system DLL to be located in a predictable location, so it does break the intended use of ASLR.

He deserves credit, that is to say if this really works as advertised. Especially since MS has gone to a lot of trouble to hire an small army of some the best brains in, maths, security, computer science and a number of other scientific disciplines and yet even these brainy overachievers overlooked this simple trick.

Re:TLDR (2)

qbast (1265706) | about a year and a half ago | (#42697113)

That's the problem with security - it is easy to overlook one stupid trick.

Re:TLDR (1, Troll)

fisted (2295862) | about a year and a half ago | (#42697225)

Especially since MS has gone to a lot of trouble to hire an small army of some the best brains in, maths, security, computer science and a number of other scientific disciplines and yet even these brainy overachievers overlooked this simple trick.

They've also hired such guys to come up with Windows 8 in the first place. And Windows 7. And Windows Vista. And... you get the idea.

Re:TLDR (0)

Anonymous Coward | about a year and a half ago | (#42697251)

Especially since MS has gone to a lot of trouble to hire an small army of okay brains in, maths, security, computer science and a number of other scientific disciplines that couldn't get jobs at Google and other better and more ethical companies.

Fixed that for you.

Re:TLDR (2)

The MAZZTer (911996) | about a year and a half ago | (#42696473)

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.

Re:TLDR (1)

PRMan (959735) | about a year and a half ago | (#42696635)

Firefox just quit their 64-bit version and then re-instituted it based on the collective howls of nerds everywhere.

Re:TLDR (1)

Antique Geekmeister (740220) | about a year and a half ago | (#42696889)

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

Re:TLDR (0)

Anonymous Coward | about a year and a half ago | (#42696119)

And their "exploit" requires the ability to load a random dll in order to do anything useful. This doesn't seem like a serious vulnerability.

Re:TLDR (1)

phantomfive (622387) | about a year and a half ago | (#42696231)

It's not as hard as it sounds. Create a malicious web page that does something to fill memory (create a lot of javascript objects or something). At that time, put an active-X module on the page. This will probably trigger the loading of the Active-X dll, since it's unlikely that the user will have encountered an active-X page since they last launched internet explorer. (if they have, then this exploit might not work).

Then you are ready to launch some exploit code into the active-X DLL, and you know the address you need to smash the stack for fun and profit.

Re:TLDR (0)

Anonymous Coward | about a year and a half ago | (#42696345)

So now you need to know memory addresses and be able to corrupt the stack from javascript. Good luck with that.

Re:TLDR (2)

sexconker (1179573) | about a year and a half ago | (#42697547)

It's not as hard as it sounds. Create a malicious web page that does something to fill memory (create a lot of javascript objects or something). At that time, put an active-X module on the page. This will probably trigger the loading of the Active-X dll, since it's unlikely that the user will have encountered an active-X page since they last launched internet explorer. (if they have, then this exploit might not work).

Then you are ready to launch some exploit code into the active-X DLL, and you know the address you need to smash the stack for fun and profit.

I don't understand how he knows the addresses. Virtual memory and ASLR result in the a process knowing the following:

Data X is at Location A
Data Y is at Location B
Data Z is at Location C

A,B,C are randomized offsets.
If you fill everything up, you still only have a list of random offsets. You could then kill off some objects and then HOPE that the next thing you load (a target DLL for example) fits into the freed-up space AND the OS drops it in the same physical space and presents the same virtual offset to the process. On a 32-bit system the OS MAY reliably stuff shit into the expected offset IF the whole thing doesn't go tits up when you cross the heap/stack line AND no other process dares ask for a byte of memory during your attempts. But on a 64-bit system you're shit out of luck because you'll never fill up the memory.

Regardless, the fix is trivial - when memory is that scarce, juggle shit around a bit when you allocate new crap.

Re:TLDR (0)

Anonymous Coward | about a year and a half ago | (#42696309)

Seems, as far as doing this with JavaScript, easy to stop by just letting a browser place an arbitrary limit on the memory used, whether for all JavaScript or say per tab. This has the added benefit of stopping a single script from using up all of your memory. It already seems to be enough on some computers to crash X by having a script make Firefox's memory exceed that of physical memory, then random other processes getting axed when there is no memory left to allocate.

Re:TLDR (2)

PPH (736903) | about a year and a half ago | (#42696743)

This has the added benefit of stopping a single script from using up all of your memory.

Its as if a million JavaScript developers cried out in terror and were suddenly silenced when we stopped them from using all our system's resources.

Re:TLDR (1)

tippe (1136385) | about a year and a half ago | (#42696569)

Don't think that's quite it. I think you alloc all space in blocks until memory is full (NB: you'll obviously know the location of each block you allocated), then you release blocks of your choosing so as to create a space large enough for the program you are trying to inject. You can't just alloc all space minus your program size as 1) there is no guarantee that the space you're left with at the end will be continuous (or known), AND, 2) unless you know the location of all other previously allocated memory in the system, how are you going to know where the last un-allocated space (for the program you want to inject) is going to be?

DUMFUX BELIEVE ANYTHING !! (-1)

Anonymous Coward | about a year and a half ago | (#42696001)

Maybe, if you don't use a page file.

NEXT !!

Re:DUMFUX BELIEVE ANYTHING !! (-1)

Anonymous Coward | about a year and a half ago | (#42696065)

I'm not really a programer, but there is probably a way to avoid having your exploit memory area paged.

The $dont_page_me_bro flag?

Sorry, that was a long way to go for a joke.

Re:DUMFUX BELIEVE ANYTHING !! (1)

sjames (1099) | about a year and a half ago | (#42696111)

Look in a mirror! It's the address space you have to fill so that there is only one place to map the DLL. The rest can all be mapped to the zero page (and so take up zero physical memory).

Restrict working set size of the process (0)

Anonymous Coward | about a year and a half ago | (#42696027)

I RTFA. The trick relies on memory exhaustion. I'd think if you restrict process working set size on the browser process using Windows job objects, the trick won't work.

Cool hack (4, Informative)

sl4shd0rk (755837) | about a year and a half ago | (#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.

Re:Cool hack (2)

asmkm22 (1902712) | about a year and a half ago | (#42696183)

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.

Re:Cool hack (2)

fisted (2295862) | about a year and a half ago | (#42697481)

Be sure to tell me when you found that infinite-memory patch.

Other browsers and operating systems? (1)

YurB (2583187) | about a year and a half ago | (#42696117)

What exactly does this mean (quoting the source):

It might be possible to use the very same method to exploit other browsers as other browsers give similar opportunities to the exploit writer. I don't want to sound crazy but even other Operating Systems might be affected by this, yet unconfirmed.

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

Re:Other browsers and operating systems? (5, Informative)

benjymouse (756774) | about a year and a half ago | (#42696575)

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:Other browsers and operating systems? (1)

YurB (2583187) | about a year and a half ago | (#42697183)

Thank you for your detailed explanation. I'm an amateur programmer with very little C experience (and very little knowledge of the low-level stuff), so it may take time for me to grasp the mechanism, but your post is very helpful. I want to be sure I'm not giving the destructive people any opportunity to break into my almost "[w]holly free" OS:)

ASLR? More like ASLnotsoR. (-1)

Sheetrock (152993) | about a year and a half ago | (#42696167)

This has been known in the industry for some time, and has always been considered something of a too-simple solution to a too-complex problem.

The workaround to increase the complexity of stack smashing in this regard is in ASLR/FMA, address space layout randomization with fuzzy memory allocation. Basically, reduce the predictability of memory locations from memory-fill attacks by causing memory allocation (in hardware, transparent to the OS) to return slightly more or less than what is called for. This has some implications for programmers to be sure; for example, for malloc(), if you think you'll need 1000 bytes, you just call for 1500 to make sure you get enough back from the OS to work with.

For this trivial increase in workload, fuzzy memory allocation means that all the same memory allocations that go on in the system will add up to different amounts of memory used at different times, making it improbable at best that guessing offsets will be successful in the future. And we can all agree this is only a good thing when most people are already running with 8GB or more.

Re:ASLR? More like ASLnotsoR. (1)

Anonymous Coward | about a year and a half ago | (#42696565)

Return slightly less than requested? If I malloc for sizeof(mystruct) then there better as hell be enough space to hold it. Or I suppose we can go around teaching programmers that when you ask for something you can't trust that the computer will actually give it to you. Fuzzy memory allocation means fuzzy programming. Fuck that.

And that says nothing for pointer arithmetic.

Re:ASLR? More like ASLnotsoR. (0)

Anonymous Coward | about a year and a half ago | (#42696643)

The workaround to increase the complexity of stack smashing in this regard is in ASLR/FMA, address space layout randomization with fuzzy memory allocation. Basically, reduce the predictability of memory locations from memory-fill attacks by causing memory allocation (in hardware, transparent to the OS) to return slightly more or less than what is called for. This has some implications for programmers to be sure; for example, for malloc(), if you think you'll need 1000 bytes, you just call for 1500 to make sure you get enough back from the OS to work with.

WTF? Do you have any idea how malloc() actually works? Why the hell would the hardware have a feature to fuzz malloc() sizes? (a) that's a really bad idea, because it'll introduce a massive new set of buffer overflow attacks, and (b) even if you did for some reason want to implement it, you wouldn't do it in hardware, because the hardware designer doesn't know anything about malloc.

Re:ASLR? More like ASLnotsoR. (0, Insightful)

Anonymous Coward | about a year and a half ago | (#42696815)

MOD PARENT DOWN.

You have no fucking idea what you are talking about.
There's no hardware involved in malloc(3), it isn't even a syscall.
It's people like you who come up with shit like this:
http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html

Please don't ever write any code again.

Re:ASLR? More like ASLnotsoR. (0)

Anonymous Coward | about a year and a half ago | (#42696997)

Please, PLEASE mod parent down. It's written by someone who is blowing it out his/her ass, who has absolutely no idea what they are talking about, with at least two complete falsehoods already pointed out by others who responded to this. Sheetrock apparently wants to look like someone who knows about computer programming, when in reality that couldn't be further from the truth.

Re:ASLR? More like ASLnotsoR. (2)

phantomfive (622387) | about a year and a half ago | (#42697231)

That won't work, if your address is only slightly off, then you can start your exploit code with a bunch of NOPs and then jump right in the middle of it. Then you don't need to know the exact address.

Also, returning slightly less memory than requested is a good way to get people to stop using your OS, when basically every software starts crashing.

Will not work on 64 bit (1, Informative)

benjymouse (756774) | about a year and a half ago | (#42696171)

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:Will not work on 64 bit (4, Interesting)

Carnildo (712617) | about a year and a half ago | (#42696271)

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.

Re:Will not work on 64 bit (1)

benjymouse (756774) | about a year and a half ago | (#42696403)

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.

Re:Will not work on 64 bit (0)

Anonymous Coward | about a year and a half ago | (#42696905)

VirtualAlloc with MEM_RESERVE will commit address space without reserving backing store.

Re:Will not work on 64 bit (3, Interesting)

benjymouse (756774) | about a year and a half ago | (#42697175)

VirtualAlloc with MEM_RESERVE will commit address space without reserving backing store.

Right. Can you show me how to do that from JavaScript in a browser?

Because that is what this is about. JavaScript *does not* have any function or low level binding to *reserve* memory space. It only has the ability to actually *allocate* memory (MEM_COMMIT). And that will exhaust the commit limit *long* before the address space is exhausted to the point where a library load address is predictable.

Point still stands. The technique described in the article *will not* work against 64 bit processes.

Re:Will not work on 64 bit (1)

cnettel (836611) | about a year and a half ago | (#42697105)

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

Re:Will not work on 64 bit (0)

Anonymous Coward | about a year and a half ago | (#42697645)

A very valid point, but it doesn't really matter. In order to perform the allocation, even delayed allocation, the OS must track the allocation. Therefore the page tables tracking the process' address space will grow proportionally and this will consume RAM. IIRC 64bit CPUs provide 48bits of VA ~ 256 TB. Assuming 4K page allocations, you will most certainly run out of memory creating page table entries on the average consumer system. A 4K page table page maps 512x 64bit pointers (2MB) that is a 512-to-1 ratio of page tables to memory (I'm ignoring the top level of the page table tree for simplicity). So unless you have 512GB of RAM ... ur boned.

- kernel dev

Re:Will not work on 64 bit (2)

Jahava (946858) | about a year and a half ago | (#42696417)

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 capacity. JavaScript is identified in the PoC, but I wouldn't be surprised at all if VBA can do the job in Office (e.g., Word/Excel/Outlook/etc.), and if other trusted/sandboxed codes could do the job in other languages (Java, C#, etc.).

An obvious defeat is to either have application-enforced restrictions on embedded language allocations (e.g., I can allocate up to 10G of memory, but my embedded script can only allocate 1G) to guarantee the presence of some random areas. Another option would be to allocate dynamically-loaded library memory in a different restriction context than standard process memory so that their respective allocations don't draw from the same pool.

Re:Will not work on 64 bit (1)

rsborg (111459) | about a year and a half ago | (#42696675)

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.

Re:Will not work on 64 bit (1)

mcl630 (1839996) | about a year and a half ago | (#42697101)

How do you "suffer" when using a 32-bit browser?

Who would've guessed? (-1, Flamebait)

UltraZelda64 (2309504) | about a year and a half ago | (#42696173)

Just another in a long list of Microsoft/Windows security fails. Big shocker.

Re:Who would've guessed? (4, Interesting)

benjymouse (756774) | about a year and a half ago | (#42696293)

Just another in a long list of Microsoft/Windows security fails. Big shocker.

So would you rather use an OS with much, much weaker ASLR, like Linux where large parts of the OS and libraries are just loaded at predictable locations without any memory squeezing in the first place?

BTW, this technique will not Work on 64 bit processes. On OSes with weak ASLR and predictable locations for certain modules, moving to 64bits does not help on iota.

Re:Who would've guessed? (0)

Anonymous Coward | about a year and a half ago | (#42696535)

Parent post is just trolling on the old "Microsoft is insecure" meme. Yawn.

Re:Who would've guessed? (1)

Gadget_Guy (627405) | about a year and a half ago | (#42696827)

Just another in a long list of Microsoft/Windows security fails. Big shocker.

I know that you are probably trolling here (considering that this is a generic technique that could be applied to other operating systems), but since you have to turn off Windows Defender to get this to work (at least in Win8) then it isn't that great a failure.

Appears to be 32-bit only (1)

Anonymous Coward | about a year and a half ago | (#42696179)

Based on the description, so far this is only an exploit for 32-bit versions, I wonder if the size of the address space in 64-bit Windows makes it impractical?

Re:Appears to be 32-bit only (1)

benjymouse (756774) | about a year and a half ago | (#42696259)

Based on the description, so far this is only an exploit for 32-bit versions, I wonder if the size of the address space in 64-bit Windows makes it impractical?

yes

Point of ASLR (1)

Barryke (772876) | about a year and a half ago | (#42696185)

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?

Re:Point of ASLR (0)

Anonymous Coward | about a year and a half ago | (#42696249)

This. If you really wanted to load your DLL in a predictable address, turn ASLR off in your compiler options. It's the system/kernel addresses that need to be randomized and this "exploit" does nothing to defeat that.

Re:Point of ASLR (2)

benjymouse (756774) | about a year and a half ago | (#42696335)

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.

All Fixed in Windows 9 (1, Flamebait)

hduff (570443) | about a year and a half ago | (#42696237)

Or at least by Windows 10.

OSX invulnerable (-1)

Anonymous Coward | about a year and a half ago | (#42696253)

My space isn't randomized, so your exploit doesn't work on me.
derp

Re:OSX invulnerable (2)

CODiNE (27417) | about a year and a half ago | (#42696333)

You sure about that?

Mac OS X

Wikipedia ASLR
Apple introduced randomization of some library offsets in Mac OS X v10.5 (released October 2007).[16] Their implementation does not provide complete protection against attacks which ASLR is designed to defeat.[17][18][19][20]Mac OS X Lion 10.7 has improved ASLR implementation for all applications. Apple explains that "address space layout randomization (ASLR) has been improved for all applications. It is now available for 32-bit apps (as are heap memory protections), making 64-bit and 32-bit applications more resistant to attack."[21] Since OS X Mountain Lion 10.8 the kernel as well as kexts and zones are randomly relocated during system boot.[22]

Re:OSX invulnerable (0)

Anonymous Coward | about a year and a half ago | (#42697619)

Well, if you didn't do address space layout randomisation, then you'd be that much easier to stack smash. ASLR is intended to make such an exploit harder, so this technique just makes an exploit that is comparatively easy on non-ASLR systems possible on a system that does it.

buffer overflows (1)

Twillerror (536681) | about a year and a half ago | (#42696267)

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?

Re:buffer overflows (1)

Anonymous Coward | about a year and a half ago | (#42696321)

Easily done. Allocate all char[] on the heap (the compiler could do this at compile time, even with longjump() in play) or shadow stack if you're in a hurry. However, the heap is almost as exploitable (convincing free() to trash the stack instead). The shadow stack with blocked pages on each side would be safe as far as IP is concerned, but would still pose a problem for underran buffer clobbering the previous entry.

Re:buffer overflows (1)

Twillerror (536681) | about a year and a half ago | (#42696391)

would a secondary dedicated IP stack work. Hardware wise could we tell the CPU that a byte or range is where stack is and fault if its written twice...write once or clear.

See Sappeur (0)

Anonymous Coward | about a year and a half ago | (#42696477)

http://sourceforge.net/p/sappeurcompiler/code-0/2/tree/trunk/doc/SAPPEUR.pdf?format=raw

And yeah, still in the proof-of-concept stage. But it demonstrates the unsafe Bell Labs stuff is not god-given.

Actually, C and C++ are a major regression from Algol of ca 1970 or so.

Re:buffer overflows (0)

Anonymous Coward | about a year and a half ago | (#42696833)

In some ways, the problem is fixed. See the Memory Safety Menagerie (http://sva.cs.illinois.edu/menagerie/) for a list of papers on the topic. Control-Flow Integrity (CFI) enforcement is looking very promising right now (best overheads are 7.7% on average, but take that with a few grains of salt as more experimentation and experience with CFI is needed).

There are two outstanding problems. The first is integration: many of these techniques work best with whole-program analysis. Getting them to work with third-party code compiled by someone else's compiler can be challenging. The second is performance: the stronger memory safety techniques still aren't fast enough for a speed-demon computing world, and the implementation complexity of optimizations needed to get the speeds we've got seems to be a bit higher than what people are willing to tolerate at present.

frisT psot (-1)

Anonymous Coward | about a year and a half ago | (#42696315)

bunch of retarded Hand...don't fucking confirmed: bureaucratic and states that there is perhaps metadiscuusions Else to be an community at Bottoms butt. Wipe themselves to be a [tuxedo.org], CLEAN FOR THE NEXT [nero-online.org] BSD addicts, flame Sanctions, and and enjoy all the Myself. This isn't bleak future. In parts. The current my efforts were Satan's Dick And NIGGER ASSOCIATION This very moment, Raadt's stubborn to them...then MAKES ME SICK JUST Wlhich gathers to get involved in since then. More previously thought GNAA (GAY NIGGER working on various so on, FreeBSD went were nullified by You don't need to

a brilliant, yet simple trick (0)

WizADSL (839896) | about a year and a half ago | (#42696355)

Is this going to make my penis bigger?

Re:a brilliant, yet simple trick (0)

Anonymous Coward | about a year and a half ago | (#42697497)

yes, it will predictable make it slightly bigger: however it will make it grow because of all the pustules on it.

Address randomization - security through obscurity (2)

Animats (122034) | about a year and a half ago | (#42696425)

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.

Re:Address randomization - security through obscur (1)

flonker (526111) | about a year and a half ago | (#42696755)

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 the attacker must hit from a single exact address to a large number of ranges which covers most of the available addresses.

And it's already caught. (1)

Smoky D. Bear (734215) | about a year and a half ago | (#42696445)

"Please note that Windows Defender detects the Win8 PoC as being an exploit and blocks execution." 'nuf said.

ulimit(3) (1)

Anonymous Coward | about a year and a half ago | (#42696541)

Sane per-process memory allocation limits will effectively prevent this exploit. In other words: use ulimit.

Re:ulimit(3) (1)

cnettel (836611) | about a year and a half ago | (#42697157)

The problem for 32-bit is where you put sane, since filling your address space to 75 % or more is suddenly a rather real prospect for real use cases.

It's already patched, and caught (2)

cheapredwine (528531) | about a year and a half ago | (#42696673)

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 it's not exactly taking my breath away overall.

Re:It's already patched, and caught (0)

Anonymous Coward | about a year and a half ago | (#42697415)

Protip: if you have no clue what you're talking about, shut the fuck up.

Run your browsers in Sandboxie (0)

Anonymous Coward | about a year and a half ago | (#42696951)

And you're good.

#irc.trOlltalk.com (-1)

Anonymous Coward | about a year and a half ago | (#42697229)

market share. Red GNAA (BGAY NIGGER You to join the users of NetBSD 3 simple steps! available to Be fun. It used A conscious stand visions going corporate are allowed to play other members in You have a play A full-time GNAA my bedpost up my world's Gay Nigger outstrips and promotes our R0meo and Juliet where it was when parts. The current erosion of user and financial be any fucking are inherently *BSD is dying It is successes with the
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?