Microsoft rushes out CVE-2013-1347 “Fix it” for the latest Internet Explorer zero-day

Remember the US Department of Labor hack we wrote about at the beginning of the month?

A microsite off the main web page was compromised and used to serve up a drive-by download cocktail that aimed to infect your computer surreptitiously.

The vulnerability that was exploited in the drive-by turned out to an unpatched bug (what’s known as a zero-day or 0-day) in Internet Explorer 8, and was soon labelled CVE-​2013-​1347.

The good news is that Microsoft had just published an emergency patch, known as a Fix it, that is simple to apply, easy to reverse if it causes any problems, and (so Redmond says) knocks the vulnerability on the head.

You can read more about the Fix it in a well-worth-reading blog post from Microsoft’s Secure Windows Initiative team.

CVE-​2013-​1347 is what’s known as a use-after-free bug.

This means that Internet Explorer continues to use blocks of memory after they have been freed (returned to the operating system’s memory pool), and therefore after they may already have been reallocated and modified.

Why is this bad?

Imagine that an attacker can come up with a sequence of operations, triggered from inside the browser (e.g. using JavaScript), that tricks Windows into reallocating those memory blocks quickly, so they can be modified from inside the browser (e.g. using more JavaScript) before the “use” part of the use-after-free takes place.

This means that the attacker can use an untrusted external web page to control with some precision the contents of memory that will later, and erroneously, be trusted and used by the buggy part of Internet Explorer that still thinks it “owns” that memory.

With a bit (or, more likely, a lot) of work, an attacker may be able to wrangle this situation into a remote code execution exploit, and that usually means he can pull off a drive-by install.

The problem with rushing out a permanent patch to this sort of bug is that there is a chance that by sealing off the flaw, you might break things that legitimate real-world websites rely on, and thus interfere with the workflow of some of your users.

Even if the behaviour broken by your patch is a side-effect of the bug, and thus itself relies on broken behaviour, users don’t like security “cures” that give the impression of being worse than the disease.

So the neat thing about this Microsoft Fix it is that it uses a load-time hack (in the entirely positive sense of the word “hack”) to patch the vulnerable code in mshtml.dll in memory when Internet Explorer loads.

The buggy mshtml.dll is not permanently replaced on disk, so that the Fix it is really easy to remove if it turns out to get in the way.

(I suspect it will not: Microsoft’s blog post does a good job of explaining how little gets changed to effect the fix. You can see the machine code of the patch in the diagram above.)

Best of all, the temporary patch won’t get in the way of the permanent patch that will surely follow.

→ Patching DLLs after they have loaded does increase program load time and memory usage very slightly, so Microsoft advises removing the Fix it after a permanent patch has been published, but that’s for the sake of neatness, not of necessity.

There are two Fix it caveats noted by Microsoft, however: you must have April’s Patch Tuesday Internet Explorer update installed, and it only works on 32-bit versions of Internet Explorer.

So if you can’t or won’t use the Fix it, here are some additional comments about this zero-day:

• It is prevented by Microsoft’s Enhanced Mitigation Experience Toolkit (EMET), which is a general-purpose sandbox wrapper for software that doesn’t do sandboxing of its own.
• It only affects Internet Explorer 8. Other versions are immune.
• The hacked Department of Labor site is off the air.
• An up-to-date anti-virus should block the malicious files from the in-the-wild exploit.

Take care out there!