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

Filed Under: Featured, Internet Explorer, Microsoft, Vulnerability

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!

, , , , , , ,

You might like

5 Responses to Microsoft rushes out CVE-2013-1347 "Fix it" for the latest Internet Explorer zero-day

  1. Richard Nodgson · 500 days ago

    Any idea on what the FixIT MSI package actually does? There are a number of mitigation methods described by Microsoft, but I can't see anything mentioning which one the FixIT patch puts into play - and so can't assess how it might affect people without testing.

    • JimboC_Security · 499 days ago

      Hi Richard,

      As described by Paul above and in the following blog post, the actions that the FixIt takes are to modify the in-memory copy of mshtml.dll specifically the CBlockContainerBlock::BuildBlockContainer function to force the layout structures of the DOM tree to be cleaned up before they are accessed:
      http://blogs.technet.com/b/srd/archive/2013/05/08...

      This means that the vulnerability cannot be exploited since the conditions it relies upon to work are then no longer present.

      An advantage of this FixIt is that it can be uninstalled (there is a link provided in the blog post that I linked to above), should you encounter any issues with it. I have seen comments on other blogs that say this is FixIt is working fine for them.

      The final patch is being tested and is scheduled for release next Tuesday, 14th May as mentioned in the following blog post:
      http://blogs.technet.com/b/msrc/archive/2013/05/0...

      I hope this helps. If I can answer any other questions, please let me know. Thank you.

    • JimboC_Security · 499 days ago

      Hi Richard,

      I should have been clearer in my previous post. The Fix It simply removes the conditions that an exploit would need to take advantage of this vulnerability. This can be described as a mitigation but it is not a mitigation that Windows or Microsoft EMET have/use (e.g. DEP, ASLR, SEHOP, Anti-ROP etc.).

      One further point I should mention is that when the final patch for this issue is made available, for any systems upon which you have installed this Fix It workaround, you should use the Uninstall link in the blog post that I mentioned in my previous post to remove the workaround.

      The reason for this is as follows (also mentioned in the same blog post):

      “However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, after you apply the yet-to-be-released final security update, you should uninstall the Fix it workaround as it will no longer be needed.”

      I hope this helps. Thank you.

  2. JimboC_Security · 500 days ago

    Kudos to Microsoft for making a Fix It available in such a short time. In addition, they intend to issue a patch for this zero day flaw next week as mentioned in the following blog post:
    http://blogs.technet.com/b/msrc/archive/2013/05/0...

    I realize that Google and Mozilla have shipped patches within hours but this is still a very good response time from Microsoft.

    Thank you.

  3. RobPalmer · 435 days ago

    I have removed- - -1347 after loading the latest (I trust updated) version of IE8. Any need to keep it? R Palmer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog