Microsoft releases emergency patch for critical IE8 zero-day exploit

Microsoft releases emergency patch for critical IE8 zero-day exploit

Summary: Users running Internet Explorer 8 — an estimated 23 percent of all IE users — should update their systems with an out-of-band emergency patch to prevent a zero-day flaw.


Microsoft has released a fix that patches a critical zero-day vulnerability that was being actively exploited in the wild.

Multiple security firms warned that Internet Explorer 8 was used to launch "watering hole" attacks at government workers at the U.S. Department of Labor and the U.S. Department of Energy. In a security advisory issued on Friday, Microsoft said it was "investigating" the reports and that it was "aware of [the] attacks." It confirmed the flaw as a "remote code execution vulnerability" that allows hackers to inject malware into a webpage or a user's computer.

All Windows versions running IE8 were at risk, including Windows Server 2003, 2008 and R2 versions, though IE6, IE7, IE9 and IE10 were not.

Today's security patch comes in form of a "Fix It" response — a small one-click application that patches systems in one go — but users are warned to install the April cumulative security update first.

Microsoft explained: "At the moment, we are aware of a limited number of attacks in the wild and they target IE8 on Windows XP only." 

However, FireEye confirmed that the exploit "could also work against IE8 on Windows 7" machines, and Microsoft listed Windows Vista, Windows 7, and its Windows Server products as "affected software."

The software giant explained how the fix works:

The vulnerability is exposed due to a page layout issue, triggered when Internet Explorer 8 is trying to calculate layout information for nodes no longer in the DOM tree. The issue is caused by layout structures that are not properly cleaned up and contain dangling pointers to page elements.

When the layout is updated, the browser crashes due to accessing the freed memory. The code that cleans up the dead links already exists, but it runs after the layout structures are accessed. The solution is to move the cleanup logic before the layout structure access.

Microsoft's Dustin Childs said in an emailed statement: "Customers should apply the Fix it or follow the workarounds listed in the advisory to help protect against the known attacks while we continue working on a security update.

Topics: Browser, Microsoft, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Hmmmmm......

    Meanwhile, back at the ranch....
    • Sisyphus?

      Is this EVER going to stop?
      Yes, I do realize the complexity of code, but, come on, folks!
      Still plugging holes into code written 10 years ago!
      In case you're inclined to be forgiving. there also are "holes" in code written 6 months ago, and yesterday as well.
      Could it be that "write first, release now, debug later" is the norm in the industry?
      • Yes, when will it ever stop?

        By "it" I mean people expecting code to be completely flawless after some period of time.
      • Meanwhile, in a different universe...

        Google releases security fixes to Chrome on a regular basis.
      • It will never end

        Good code old or new... weakness will be found and exploited. Money will always push up the release date. I do not think anyone is willing to wait the ammount of time it would take to get code near perfect prior to release.
      • Probably Never

        When I worked in the computer industry the normal management response to correcting product issues was to first measure the level of customer pain caused by the issue. If there were only a few complaints, the issue would not be looked at even though it was know to be a problem. Simply put, the level of pain experienced by the customer base had to exceed a defined level before money was spent to correct product issues.
  • I'd really like to see information on how...

    ...protected mode may help mitigate code execution exploits. While it won't prevent the code from execution it should vastly minimize its impact. Even moreso with Enhanced Protected Mode.
    • Or even better...

      Perhaps an explanation of why IE8's "protected mode" didn't protect against this attack.
      • That's the problem: We don't know if it didn't.

        Protected Mode wasn't designed to prevent code execution but rather limit what executing code can modify. It's possible the exploit code could be executing within the restrictions of Protected Mode.
        • The point surely being...

          That it still executed "enough" to install its payload successfully.
          • Do we know this?

            "That it still executed "enough" to install its payload successfully."

            What are the details? I have not seen any details about how this malware infects the system. While you may consider it unimportant in the context of it was an infection it is important in determining how to prevent it from happening in the future. That's why I'd like to see an analysis.

            All too often we hear "Remote code execution" but given Protected Mode wasn't designed to stop code executions that doesn't tell us much. Was the process able to write to areas protected by Protected Mode? If so was the code running in one of the zones with Protected Mode enabled? If not why not? If so how did it bypass Protected Mode? Or did it...possible it wrote to sections of the system not protected by Protected Mode?
          • There's still the original analysis...

            This analysis was done by a commercial company, of course. But you can at least see the kind of things that the malware was able to do after successfully installing itself.

            http /2013/05/k-i-a-us-dol-website-pushing-poison-ivy-cve-2012-4792/
          • The problem is it appears the analysis was performed on...

            ...a Windows XP system. From the analysis:

            "Armed with an Invincea protected browser (IE8, Windows XP 32-bit), we decided to investigate further."

            From the Alien Vault analysis:

            "The malware will create a copy of itself in Documents and Settings\[CURRENT_USER]\Application Data\conime.exe"

            The directory "Documents and Settings" implies Windows XP. It has been replaced with "Users" starting with Vista.

            Given Protected Mode was not available in Windows XP do we have any examples of this malware infecting systems with Protected Mode functioning?
          • ye: "The problem is it appears the analysis was performed on..."

            ye wrote:
            "Given Protected Mode was not available in Windows XP do we have any examples of this malware infecting systems with Protected Mode functioning?

            There's this blog article from Metasploit where the exploit ran on "fully patched Windows 7 with IE8":


            The question is whether or not notepad, which was spawned by IE8, is running at low integrity level or medium integrity level. The article doesn't say one way or the other.

            You can download Metasploit (it's free), install it on one of your systems, test the exploit and let us all know ... [It would help if you had Sysinternal's Process Explorer installed and running so that you could view processes integrity level.]
            Rabid Howler Monkey
          • And now we're back to my original comment.

            "The question is whether or not notepad, which was spawned by IE8, is running at low integrity level or medium integrity level. The article doesn't say one way or the other."

            This is what I'm asking for: How does Protected Mode fit into this. Merely being able to run Notepad doesn't mean Protected Mode has failed as the goal behind Protected Mode was not to prevent code execution.

            I'm familiar with Metasploit as I have it installed on my Ubuntu system. I might try it out if I feel like installing a copy of Windows 7 so I can test it (my current Windows 7 system is running IE 10).
          • Metasploit Test

            Unfortunately I am unable to test this with Metasploit as the exploit doesn't appear to be working. I installed a new copy of Windows 7 in a Virtual Box virtual machine, applied all the security patches, and launched metasploit module:

            "exploit/windows/browser/ie_cgenericelement_uaf" - Microsoft Internet Explorer CGenericElement Object Use-After-Free Vulnerability

            I am unable to establish either a command line or Meterpreter session when I browse to the exploit hosted web server.
          • ye: "Metasploit Test"

            Thanks for giving it a go. I'm still scratching my head trying to understand why Rapid7 didn't see fit to provide this information (regarding the integrity level that notepad.exe runs at in the exploit) in their blog.
            Rabid Howler Monkey
          • They targeted XP users

            The attack targeted computers running Windows XP. Protected mode is based on features introduced in Vista. Worst, it is very likely that XP users run their account as system administrators.

            In addition, even on Vista and above, IE protected mode doesn't prevent reading of any data accessible to the user. Enhanced mode does. But none of this protection is available to XP users.

            Understanding and Working in Protected Mode Internet Explorer

            Understanding Enhanced Protected Mode
  • Microsoft releases emergency patch for critical IE8 zero-day exploit

    Kudos to Microsoft for quickly releasing a patch for this.
    • Interesting....

      It's a zero-day exploit for Internet Explorer 8 on Windows XP... and you're congratulating Microsoft for **QUICKLY** releasing a patch for this? A 12 year old OS and a 7 year old browser.... and you use the word "quickly"? Really?!