Update For EMET 3.5 AllROP.XML

I’ve updated the AllROP.XML file to include Java 7. I’ve also disabled Anti-ROP techniques for Explorer.exe – you can reenable at your own risk but I think some programs that add context menus can break explorer when incompatible. Also disabled EAF for explorer.exe.

For more information on Emet 3.5 Tech Preview read here.

You can download the new AllROP.XML:


EMET 3.5 Is Out – ROP Mitigations

See the 3.5 guide here:



EMET 3.5 Tech Preview is out. Installation and setup go exactly like they did before but now you get a fancy ROP tab for Microsofts latest mitigation techniques.

This is a big update. I’m super busy lately but I’m excited to blog about this.

See this link for setting up EMET 3.0 and get EMET 3.5 here. The 3.0 guide still applies you just need to manually set the ROP page.

I’ll write a guide when the final version is released.

ROP page shown here:


The new ROP mitigations are from the BlueHat competition that Microsoft used to fund research. I wrote it about it when they came out and explained that I saw some issues. Microsoft actually sees the same issues and they write about it in the TechNet article. I articulated it terribly at the time but the general idea is that these listen to specific instructions and an attacker can just use other instructions. It makes things harder, not impossible. My wording was something like “It’s detecting x but an attacker can use y” and Microsoft puts it much nicer:


Known limitations

As stated above, as long as one of the critical functions is called then ROP checks will take place. It is possible for the attacker to circumvent this by not calling any of the hooked functions (for example directly calling into NTDLL and not kernel32) or just circumventing the hook.

Again, super busy. But I’m excited and you should be too.

Try out EMET 3.5 for a more robust and hardened system. It’s well worth installing.

New Anti-ROP From Microsoft

Microsoft held a contest for computer scientists to come up with new ways to stop Return Oriented Programming (ROP) – a  technique used by hackers that allows them to easily bypass Data Execution Prevention (DEP.) Currently the most common anti-ROP technology is ASLR, headed by PaX. ASLR attempts to randomize as much of the address space as possible, which makes it difficult for hackers to find code that they can use for ROP. ASLR leaves much to be desired as if any part of the address space is not randomized it’s enough for an attacker to craft a ROP attack. There will always be static areas of address space.

Other techniques like EAF aren’t great, better for legacy exploits. And I’ve written before about techniques for defeating ROP.

Microsoft’s competition yielded three ‘top’ contributions and while the details aren’t entirely revealed I’m gonna comment on each based on the very tiny amount of information provided.

First is Jared DeMott’s /ROP.

To understand it you should know that ROP basically works by taking the compiled library and controlling the order that it executes… sorta. It means that absolutely no new code needs to be added to exploit the system.

The idea of /ROP is to check return instructions. This seems like a great idea, after all, return oriented programming without the return… just doesn’t work.

Without details it’s hard to criticize except that you don’t need return instructions for ROP. You can use ‘return-like’ instructions, which can do the same thing and create exploits just as well. What about jmp?

It’s also a detection system and only works on *known* areas of ROP. That doesn’t sound like such a big deal but it really is. It doesn’t stop anything fundamental, not really, and it’s reactive.

 Ivan Fratric

Ivan’s works by labeling specific functions as critical for ROP. And when those functions are called a check is made.

This reminds me a lot of EAF. We’ll see how it works and if it works in the real world.

Again, detection.

Vasilis Pappas

No clue how this one will work out, not enough detail given at all to make any kind of statement.

If one could simple remove the ability to ROP with magic or some such thing it would force attackers to come up with entirely new methods of exploitation. ROP is the way to get into a system right now. Hopefully one of these really does the trick. Personally I don’t quite understand why specific libraries aren’t compiled without gadgets – there are a few universally static areas of the Windows OS, why not just remove the gadgets? I really don’t know, probably some patenting bullshit.

Hopefully one of these actually drives up the cost. There just isn’t a ton of information out there right now.

I’d love to see more of these types of bounties in the future. Not patches, actual new techniques.

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



A Tip For Those Looking To Lock Down Windows

In my last post I explaining why I won’t be buying ATI until they fix their insecure drivers. This reminded me that Windows does actually have a little-known ability to run the entire system with ASLR enabled. Of course, this can lead to instability and in the case of those of you running ATI cards you will BSOD immediately but if you’re willing to take the risk it’s one more way to lock down Windows.

First, I suggest you take a look at this guide for securing Windows and this guide for setting up EMET.

This short guide will get your ASLR Always On setting enabled in the EMET User Interface.

If you’ve followed the guides you can:

1) Open Regedit


3) Change ‘EnableUnsafeSettings’ to ‘1’

4) Go to your EMET GUI and System Settings – turn ASLR to Always On. If it isn’t there you may need to reboot first.

5) Reboot

Your system might crash in which case you need to go into Safe Mode and disable this. It should go without saying that this risk falls on you, I’ll feel pretty bad if I break your computer but there’s fair warning here.

So now instead of applications having to explicitly opt into using ASLR on Windows your entire system should be running with it. This will probably break a few programs but if it works, great, you’re somewhat potentially more secure.