Universal ASLR Bypasses And How To Solve Them

Address Space Layout Randomization is an exploit mitigation technique that focuses on preventing Return Oriented Programming attacks. It’s become one of the “must have” tools for a secure program (like DEP) and it’s preset in all modern user-oriented operating systems.

Mitigating ROP is pretty important as most modern exploits take advantage of it. And ASLR would be entirely effective in an ideal world where every single part of address space is randomized and 64bit address space is impossible to bruteforce and heapspray doesn’t exist. We don’t live in that world and there are universal ASLR bypasses for Windows and Linux, heapspray does exist, and the majority of users are stuck in a 32bit address space (and 64bit vanilla ASLR isn’t necessarily impossible to bruteforce).

Windows is actually pretty on top of things with ASLR (as of Windows 8) and /FORCEASLR but there’s always going to be a way around it (unless some things seriously change.)

So what’s the answer?

Well, for non-performance critical applications perhaps a solution like Gadgetless Binaries would be a viable option. Gadgetless binaries would compile code in such a way that an attacker would be unable to make use of static address space instructions to form their attack.

There is a performance hit here so I’m not saying to compile everything with it, but for security critical applications why not? There are specific areas of Windows address space that are loaded in the same exact place every time – why not compile that area with gadgetless binaries and avoid situations like this?

There’s also a somewhat less effective In-Place Code  Randomization technique and even less effective (though still welcome) EAF, which is what Microsoft has implemented.

Perhaps I’m just missing something. Maybe this would require paying out or some such thing but it seems like a great idea to me as ASLR isn’t going to solve every problem. At least not with current implementations (outside of PaX ASLR, which makes use of many other features via Grsecurity to prevent attacks against ASLR).

Sources:

http://iseclab.org/papers/gfree.pdf

EMET – A Windows Security Tool That Everyone Should Use

Techniques like ASLR and DEP have made exploitation of modern software more difficult. And yet many programs still don’t make use of them. Why? Well, sometimes it’s a matter of compatibility but very often it’s simply a matter of the developer not knowing or not caring enough to implement them.

EMET sets out to fix this.

There are very few programs that I think belong on every single computer. EMET is one of those few.

What is it?

EMET is the Enhanced Mitigation Experience Toolkit and it’s pretty damn cool. The goal of EMET is to prevent programs from being exploited by forcing them to make use of modern mitigation techniques (EAF, SEHOP, ASLR, DEP, HeapSpray, Bottom Up Randomization.)

The Good

EMET attempts to bring insecure programs like Java (which is the most exploited piece of software for Windows users) up to speed in terms of security. By running Java with EMET you can prevent a ton of exploits that would have otherwise led to infection. You can also run your browser with EMET to prevent Flash/ browser exploits.

EMET also uses virtually no resources. EMET.dll is something like 44kb and that’s all that’s loaded into programs. The mitigation techniques should have a negligible effect on performance as well.

Compatibility is easy to maintain as EMET can be used on a per-program basis. I suggest that you run your PDF viewer and Java with EMET and consider running your browser as well.

Windows XP users should be downloading EMET as soon as possible. XP doesn’t have any form of ASLR but EMET will provide EAF, which is another ROP mitigation (though less effective.)

The Bad

EMET is not a replacement for an antivirus. It offers absolutely no detection of malware or malicious activity – its only goal is to prevent exploitation.

Even with all of those mitigation techniques there are ways around them; DEP and ASLR just don’t apply to every situation ie: JIT Spraying, which needs a whole separate class of mitigation. EMET drives up the cost of exploit, it doesn’t eliminate the threat.

Some of the techniques like EAF and HeapSpray are also easily bypassed, they’re more for defeating automated attacks, which is still valuable since that’s what the average user will come across.

There are potential compatibility issues with EMET. Very old programs can’t handle DEP and they’ll potentially break even if you just install EMET. It sucks. I suggest you contact the developer and remove EMET in the meantime.

It should be plain to see why EMET is such a significant security tool. Forcing horribly insecure programs like Java to start acting like modern software is probably the most important first step in securing Windows. EMET is a must have, whether you’re on XP, Vista, or 7.

I’ll be posting a guide with screenshots on how to set up EMET very soon.

Grab EMET Here:

https://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx?Redirected=true