As you are probably aware, Microsoft’s October 2013 Patch Tuesday includes an update for Internet Explorer that closes no fewer than ten RCEs, or Remote Code Execution holes.
This sort of vulnerability means that merely looking at a booby-trapped web page could infect you with malware, even if you don’t click on anything on the page.
Unfortunately, an exploit that takes advantage of one those ten holes, CVE-2013-3893, is known to be in the wild.
Cybercriminals have been using it; a proof-of-concept HTML page has been published that you can tweak for your own attacks; and the popular penetration tool Metasploit now includes it.
So rather than just leave you to apply the patch and be done with it, we thought we’d look at this exploit in some detail.
We hope that this will help you understand the lengths that cybercriminals will go to in order to attack your computer, despite the layers of protection that modern versions of Windows and Internet Explorer include.
Don’t worry if you aren’t technical: we’ve tried to keep the assembler code and the programming jargon to a minimum.
Just glide over anything you don’t understand and get a feeling for how cyberattackers think – “know thine enemy” is a handy part of any defence.
And, no, we haven’t given away so much that you can turn this article into an attack of your own: it’s an explanatory guide, not a how-to tutorial.
The core of the hole
Our attackers will be exploiting a bug in Internet Explorer’s mouse capture functionality.
This is done using the functions setCapture() and releaseCapture().
An object can also declare an onclosecapture function, which will automatically be called if ever it loses control of the mouse, for example because another object calls setCapture() to take over.
Our attackers seem to have discovered that these functions can be used to trick Internet Explorer, by orchestrating an unusual sequence of operations, something like this:
-  Create 10,000 items in the current web page, giving each one a title string of “3333….3333”.
-  Free the memory of the last 5000 items by setting the title back to a blank string.
-  Create two more items, making one the parent of the other.
-  Set an onclosecapture event for the child item, in which 10,000 more items entitled “3333….3333” will be created.
-  Call setCapture() from the child item.
-  Call setCapture() from the parent (thus causing the onclosecapture from  to be called in the child item).
What it does
Here’s what you see if you run the trigger code that does this under a debugger, using Windows 7 with Internet Explorer 9:
If you aren’t familiar with debuggers, this window tells you that the program has crashed at the address 0x6AA33859 in the system library MSHTML.DLL, trying to run the instruction:
(In Intel assember notation, data flows from right to left, so this means “move the value of [ECX] into the register EDX”. And the square brackets mean “fetch the value at the memory address stored in ECX, not the value of ECX itself.” The DS: just denotes that the value comes from the processor’s data segment.)
To explain further, the code at and after the offending instruction above does the following:
MOV EDX,[ECX] ; Fetch the contents of the ; memory address in ECX, ; where ECX is controlled ; by the string in  and  ; on the attacker's web page. MOV EAX,[EDX+C4] ; Fetch the contents of the ; address C4 bytes past that. CALL EAX ; And call it as a subroutine.
The exception occurs because ECX = 0x33333333 (the ASCII code for the text string “3333”), but there is no memory allocated at that address for the processor to read.
It looks as though memory that was freed up in  was then re-used by Internet Explorer to store data that controls the flow of execution in MSHTML.DLL (Microsoft’s rendering engine), and then wrongly re-used against for saving the text strings created in .
That’s a use after free bug, and in this case, it means our attackers can lead Internet Explorer astray: they can trick the browser into using untrusted data from their remote web page to tell your computer where to jump next in memory.
That means there is very likely to be a chance for RCE, or Remote Code Execution.
The next step
To make further headway, the attackers needed to to force ECX to contain the address of memory that is allocated, and that they can influence.
Adding a step [4.5] to the list above does the trick:
- [4.5] Create 320 text strings that take up 1MB each, containing the bytes 0x12121212 repeated over and over.
If we run Internet Explorer again until it crashes, and then peek at the memory blocks allocated by Windows, we can see the results of the heap spray.
The size column shows that these blocks are all 0x00100000 bytes in length, or 1MB:
Each of those blocks is crammed with the bytes 0x1212….1212.
Notice particularly – and we shall soon see why this is terribly convenient – that the memory block containing the address 0x12121212 (and the address 0x121212D6, which is 0xC4 bytes further on), is one of the chunks filled with 0x1212….1212.
Finding the right size for each heap spray object, and the right number of memory allocations to perform in order to get a neat and exploitable result, doesn’t need to be done analytically.
Cybercriminals can save time and effort simply by using trial and error – a process that can be automated.
So, instead of using the text string “3333”, as in steps  and  above, our attackers can choose a value that corresponds to an address inside one of the blocks they know their heap spray will produce.
In the published exploit, they chose 0x12121202, though many others would have done just as well, so that steps  and  no longer have ECX set to “3333”.
Instead, ECX becomes 0x12121202, and the crooks get this:
; EDX gets the contents of 12121202 MOV EDX, ; EDX is now 12121212, so ; EAX gets the contents of EDX+C4 (121212D6) MOV EAX, [12121212+C4] ; EAX is now 12121212, which we call CALL 12121212 ; Execution is now at an address we control!
On versions of Windows before XP SP3, the attackers would already have won the battle at this point, by adapting the text strings from [4.5] so that they contained shellcode (executable code hidden in chunks of data) starting at 0x12121212 , thus instantly getting control.
But these days (and we’re on Windows 7 in this article, remember), memory blocks dished out by the operating system – allocations “on the heap”, as they are known – are set to be NX, or No Execute, by default.
If you try to execute an instruction in a memory page marked NX, the processor steps in and stops you.
This is the basis of DEP, or Data Execution Prevention, and it means that even though our attackers can control exactly what is at address 0x12121212, and divert the processor to it, they can’t make it run:
On Windows XP, DEP slows the attackers down a bit, but not much: all they need to do is to tweak the heap spray so that the value at 0x121212D6 is an address in executable memory.
(0x121212D6, remember, is 0x12121212+0xC4: that’s where the CPU will jump as a side-effect of triggering this bug, due to the CALL EAX instruction shown above.)
The richest sources of ready-to-use executable memory are the numerous system DLLs that are almost always loaded, such as KERNEL32.DLL, USER32.DLL and GDI32.DLL.
Getting around ASLR
On Windows 7, however, picking addresses in system DLLs is much harder than it sounds, because of ASLR, or Address Space Layout Randomisation.
For example, here’s a table from our test computer, showing where Internet Explorer and its first few DLLs are supposed to load, and where they actually loaded on three successive reboots:
- DEP stops attackers with a vulnerability like this one from jumping straight to their shellcode as soon as the exploit gets control.
- ASLR stops attackers from bypassing DEP by jumping into a system DLL, because they don’t know where it will be in memory.
→ On Windows XP, system DLLs load at the same place every time, on every computer, making XP much easier to hack. That alone is enough reason to ditch XP as soon as you can, regardless of the looming “no more patches” deadline of April 2014.
But our attackers have a way around this, because some common and popular DLLs still advertise themselves as incompatible with ASLR, and are therefore loaded without it.
If you have Office 2007 or Office 2010 installed, trying to open an ms-help:// URL causes Internet Explorer to load the support library hxds.dll:
Sadly, the address 0x51BD0000 is exactly where this DLL always loads, because it was compiled by Microsoft without the so-called DYNAMICBASE option, thus causing it to be left out of ASLR:
Admittedly, this restricts the attackers to infecting computers on which Office is installed – but in practice, that isn’t a major limitation: even if you don’t own Office, you may well have a demo version left over from when you bought your PC.
At this point, our attackers are on the brink of controlling your computer, having evaded all of the following:
- Windows memory management.
- Data Execution Prevention.
- Address Space Layout Randomisation.
The good news is that they still have a fair amount of work to do.
Before they can go any further, for example, they need to choose which address in hxds.dll they will write at offset 0x121212D6, to be the target of the fateful CALL EAX that will give them their first unlawfully executed machine code instruction.
The bad news, of course, is we already know that our crooks are going to succeed in the end.
So, please join us in Part Two, where we’ll show you what they are going to do next, and why, and how you can detect and prevent their nefarious activities.
NB. Sophos Anti-Virus on all platforms detects and blocks this exploit as Exp/20133892-B.
Image of shattered glass courtesy of Shutterstock.
19 comments on “Anatomy of an exploit – inside the CVE-2013-3893 Internet Explorer zero-day – Part 1”
good blog , well explained, it would have even better if you had explained using windbg ,
Well, as the post says, "this is an explanatory guide, not a how-to tutorial," so I am not convinced that the choice of debugger matters that much, or even at all.
Nevertheless, I deliberately decided to use OllyDbg for several reasons:
* It looks good in screenshots (and the limited width we have here – 500 pixels – is ideally served by Olly's default font and layout).
* For readers who might be encouraged to try a debugger for the first time, Olly is IMO easier to download, install and get started with.
* Olly is under active development again, with v2 having been released in the past couple of weeks.
* The exploit is 32-bit only, so a 32-bit debugger seemed satisfactory to me.
Maybe an article about Windbag might do the trick? "Anatomy of a debugger" 🙂
Anatomy of a debugger would be awesome!
That said there are some very good tutorials and blog posts on .net debugging with windbg (and windbg use) at Tess Ferrandez's blog (well until she changed groups at Ms) http://blogs.msdn.com/b/tess/
One advantage would be that the MSHTML symbols can be used.
I'm not saying "don't use Windbag," just saying that in this case, Olly was the right tool at the right time 🙂
It looks like you may have left out part of the PoC where id_1 is declared.
Great article. Looking forward to part 2.
It's exploits like this that make me feel grateful I use Firefox (running in the sandfox sandbox) along with the NoScripts add-on.
Firefox isn't immune to RCE exploits, of course. (IIRC, all the major browsers have stumbled at PWN2OWN, for instance.)
Recently, the long term support version of FF used in the Tor Broswer Bundle was targeted (allegedly by law enforcement) with an exploit that could extract your computer's IP number.
But it sounds like you've done a fair bit of "defence in depth," which is a good approach.
I can't wait for part two Paul. Hopefully part two won't tell us to uninstall Microsoft Office. I actually went and purchased the office suite a few months ago because I needed it.
No, you can keep Office. It's a poor lookout that the hxds.dll wasn't compiled with DYNAMICBASE, but ditching Office on that basis alone is probably a step too far.
Do you think I am right to feel more secure using Firefox and Chromium in Ubuntu Linux?
Safer, maybe, if only because desktop Linux is a tiny-minority platform.
If you measure insecurity by the amount of bandwidth my Ubuntu netbook has consumed downloading security updates since 13.04 came out , and by the number of reboots I've had to do because something needing changing in the kernel…i ought to be quaking in my boots 🙂
And if you measure the insecurity of Linux systems by counting the number of servers compromised each day by crooks so they can target Windows desktop users, then…
…well, we're all in it together. Do you patch regularly? Do you use a Linux anti-virus? Are you using full disk encryption? Are you an inveterate downloader-and-installer?
Patch regularly, yes. Linux anti-virus, no. Full disk encryption, yes. I don't download a whole lot, when I do it's mostly scripting languages like R or Python, or media like PDFs, AVIs, or MPEGs, and of course, web content. I try to stick to reputable sources. I'm thinking the patches are more frequent because they prefer greater frequency.
is there a possibility that this can be exploited on a system with Win 8.1 RTM x64, Office 2013 x64 with EMET 4.0 enabled using "always on" for DEP, SEHOP and ASLR when IE 11 is in 64 bit Enhanced Protected Mode (EPM)?
Not *this* exploit, which is 32-bit only, and only up to IE9, if memory serves.
But Microsoft's CVE-2013-3983 patch was explicitly documented as covering Windows 8.1 and IE 11, so if you want to be sure that no other exploit could target the vulnerability behind this stuff…
…you need to apply the patch.
EMET 4.0 with "force ASLR on" is a good plan in general. It would stop this specific exploit working because the addresses the crooks chose in hxds.dll (coming in Part 2, folks!) would end up wrong, so the shellcode wouldn't work, and that would be the end of the road for the crooks.
I'd hate to see how many bugs like this are in my programs… If MS can't get it right, how can I?
very nice article! when is part 2 due?
Thanks for a brilliantly comprehensible and superbly informative article (as usual), Paul. This is the kind of stuff that keeps me coming back to NakedSecurity as my go-to source for security info. Looking forward to Part 2.
p.s. Minor typos: "…take or relinquish control over the mouse events that happen in the brower window…" (browser)
"…and then wrongly re-used against for saving the text strings created in ." (again)