Bypassing EMET 3.5′s ROP Mitigations

[Breakfastofchumps]

UPDATE : It seems MS was aware of this kind of bypasses, so I bypassed EMET ROP mitigations using another EMET’s implementation mistake. EMET team forget about the KernelBase.dll and left all its functions unprotected. so I used @antic0de‘s method for finding base address of kernelbase.dll at run-time, then I used VirtualProtect inside the kernelbase.dll, not ntdll.dll or krenel32.dll. you can get new exploit at the end of this post.

I have managed to bypass EMET 3.5, which is recently released after Microsoft BlueHat Prize, and wrote full-functioning exploit for CVE-2011-1260 (I choosed this CVE randomly!) with all EMET’s ROP mitigation enabled.

Any truth in this article?

https://repret.wordpress.com/2012/08...p-mitigations/

[Hungry Man]

Yes, it's true. This was discussed in the EMET topic.

Unfortunately for Windows users there are a select few areas of a programs address space that will always remain static - no matter if you're using EMET or ASLR Always On or not.

This demonstrates that even a single area of address space is sufficient for an attacker to bypass ASLR.

Once they've done that it's a matter of bypassing EMET's new Anti-ROP mitigations, which isn't very difficult.

This doesn't mean EMET is 'broken' or 'weak' - it's still going to protect you from exploits, it's still going to make exploits harder to write, and generic exploitation of a program running EMET is still difficult.

[jmonge]

very true

[Breakfastofchumps]

Thank you Hungry Man.