IE remote code execution vulnerability being actively exploited in the wild

A critical Internet Explorer vulnerability, announced and patched by Microsoft in June’s Patch Tuesday, is being exploited in the wild.

The vulnerability is CVE-2012-1875 (don’t expect any detail – this link is just boilerplate stuff), patched in MS12-037.

SophosLabs has seen numerous attempts to exploit this vulnerability (Sophos products detect it as Exp/20121875-A).

Cunningly-crafted JavaScript code – which can be embedded in a web page to foist the exploit on unsuspecting vistors – is circulating freely on the internet.

Also, the Metasploit exploitation framework now has a plug-in module which will generate malicious JavaScript for you on-the-fly to help you automate an attack. (For authorised penetration testing and research purposes only, natch!)

The vulnerability carries the resounding name of “Same ID Property Remote Code Execution Vulnerability”, and is caused by memory mismanagement in Internet Explorer.

This is what is generally known as a use after free bug. This happens when a program returns a surplus block of memory to the operating system, so it can be allocated again later, but nevertheless carries on using it, by which time it may unexpectedly have been altered.

Two technologies in modern operating system distributions are used to make exploits of this sort harder: DEP (data execution prevention) and ASLR (address-space layout randomisation).

DEP allocates memory blocks so they can be used for data only, not for executable code, which reduces the surface area into which hackers can poke their malicious shellcode.

ASLR loads software modules such as DLLs into memory at randomised locations.

Moving system DLLs around makes it harder for hackers to guess where to find the library functions they need, such as URLDownloadToFile() and CreateProcess().

But DEP and ASLR don’t make remote code execution attacks impossible – just trickier.

In the case of Exp/20121875-A, ASLR can be bypassed by trying to force Internet Explorer to find and load an old version of the Microsoft C runtime DLL – one which was compiled before ASLR become the norm, and therefore doesn’t support it.

Whenever you load a non-ASLR DLL, even into an ASLR-enabled program, you can predict where it will end up. (According to the aforementioned Metasploit module, your Java Runtime could be a handy source of a suitably old-school DLL).

And DEP is bypassed using a technique known as ROP, or return-oriented programming.

ROP is tricky to explain in one sentence, but it relies on knowing where to find small fragments of code in already-loaded and already-executable memory – typically just one or two instructions at a time – which can be stitched together into a coherent and malicious, albeit curious and clumsy, whole.

You then execute these tiny instruction fragments (known as gadgets in the ROP community) by building a list of memory addresses which will be jumped to in sequence using the RETURN instruction – which is where the ‘R’ in ROP comes from.

(See how tricky it was to explain ROP in one sentence? Tricky enough that I used two.)

DEP prevents code from running in system-allocated memory, but it doesn’t prevent code from being jumped to via code pointers stored in execution-prevented memory. And with ASLR quashed, you can work out in advance where your ROP gadgets will be, and construct your list of code pointers accordingly.

So much for the hackers’ efforts.

Your response is easy: if you haven’t patched already, do so right away!

NB. This exploit is not the same as the one associated with news of “state-sponsored attackers” and Google. That’s CVE-2012-1889 – another exploit that SophosLabs has seen in the wild, and that we suggest you read up about!