Microsoft advises on IE zero-day vulnerability

Microsoft advises on IE zero-day vulnerability

Summary: The zero day exploit reported last week as affecting only Internet Explorer 10 also affects IE 9. Microsoft has released a "Fix it".


Microsoft has issued a security advisory for a vulnerability in Internet Explorer 9 and 10 being exploited in the wild.

We wrote last week on the initial reports of exploits in the wild, as reported by security firm Fireeye. Fireeye and Symantec are both credited in the Microsoft advisory as having worked with Microsoft on the issue.

The vulnerability is a "use after free" remote code execution vulnerability. As in the case found by Fireeye, it can lead to a system being taken over if the user is lured to visit a web site in a vulnerable browser. The vulnerability does not, on its own, elevate privilege, so if the user is running unprivileged, the exploit will also be unprivileged.

Internet Explorer 9 is vulnerable according to Microsoft, although the actual exploits in the wild are only targeting Internet Explorer 10. Microsoft says that IE versions 6, 7, 8 and 11 are not vulnerable, so if you are on a platform which supports it, upgrading to IE 11 will address the issue.


Alternatively, Microsoft has issued a Fix it, which is a patch that blocks the actual exploits observed in the wild, but which doesn't fix the underlying vulnerability. If you need to keep running IE 9 or 10, installing the Fix it is a good idea. The Fix it requires that the user first install all the current security updates for IE 9 or 10. Another effective block against the attacks observed so far is to install the Microsoft Enhanced Mitigation Experience Toolkit (EMET), as the exploit checks to see if it is installed and exits if it is.

The table below shows which versions are vulnerable and which are under attack:

  Windows XP
Server 2003
Windows Vista
Server 2008
Windows 7
Server 2008 R2
Windows 8
Server 2012
Windows 8.1
Server 2012 R2
Internet Explorer 6 Not vulnerable n/a n/a n/a n/a
Internet Explorer 7 Not vulnerable Not vulnerable n/a n/a n/a
Internet Explorer 8 Not vulnerable Not vulnerable Not vulnerable n/a n/a
Internet Explorer 9 n/a Vulnerable,
not under attack
not under attack
n/a n/a
Internet Explorer 10 n/a n/a Under attack Under attack n/a
Internet Explorer 11 n/a n/a Not vulnerable n/a Not vulnerable

A Microsoft Security Research and Defense blog entry goes into gritty detail about how both the vulnerability and the Fix it work.

Boilerplate language in the advisory says that when Microsoft has completed their investigation they will take appropriate action, which may include an update on a regular Patch Tuesday or an out-of-band update.

Topics: Security, Microsoft, Windows

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
  • Hmm

    Maybe Microsoft should get up on its hind legs and offer IE 11 to the millions of users who cannot get it now.

    Oh yeah, they want to throw the faithful Vista users under the bus along with Windows XP, I forgot. Oh well, there's always Android.
    • Vista down near 3 percent

      Why waste time on that?
    • dilettante: "throw the faithful Vista users under the bus"

      Mainstream support for Windows Vista ended in April, 2012. (Note that Internet Explorer 10 was released in September, 2012.) That means no new features after this date (including IE 11). Security updates will be provided for IE 7, 8 and 9 on Vista until extended support for ends in 2017.

      I'm a Windows Vista user and don't consider this as being thrown "under the bus".
      Rabid Howler Monkey
  • There seems to be a lot of these IE zero-day vulnerabilities

    Not that other vendor's products are necessarily more "safe" to use.
  • Does switching DEP to "AlwaysOn" mode help?

    The default mode for DEP appears to be "OptOut", which means that cunning malware can trick Windows into spawning a new process with DEP disabled. But that's not possible if you switch DEP into "AlwaysOn" mode:

    From a command window:
    bcdedit.exe /set {current} nx AlwaysOn

    And then reboot. This obviously wouldn't resolve the "use-before-free" bug in IE, but I'm wondering if it might prevent the exploit from working.
    • Maybe a little

      Malware can't switch anything on or off unless it's already infected your system. Game over at that point, and I've never heard of malware doing this. More to the point, there are ways to bypass DEP. So there are cases where it would help, but it's not a big deal, and may cause crashes in cases where software erroneously, but harmlessly executed code in an area of memory marked as data.
      • I don't think we're understanding each other.

        "Malware can't switch anything on or off unless it's already infected your system."

        Hmm, as I understand the concept of "bypassing DEP", a process locates an existing "CreateProcess" API call in an executable and then invokes it with a brand new argument list on the stack. This new argument list includes a parameter to "opt out" of DEP, meaning that the newly spawned process will be free to execute data. However, this "opt out" can only work if the system has been configured to allow opt outs in the first place. By configuring your system such that DEP is "AlwaysOn", any malware that requests an opt-out will be denied - and probably crash.

        "but it's not a big deal, and may cause crashes in cases where software erroneously, but harmlessly executed code in an area of memory marked as data."

        We'll have to agree to differ about this. The whole point of DEP is that executing data is a dangerous and exploitable practice which legitimate processes have no business doing. Granted, it's too late to impose this restriction on old 32 bit executables, but x86_64 is a brand new environment where "DEP is AlwaysOn" could have been imposed from the beginning.
  • Another mitigation: Internet Explorer Enhanced Security Configuration

    Sadly, IE ESC is only available on Windows Server OSs: Windows Server 2003, 2008, 2008 R2, 2012 and 2012 R2.

    Managing one's legitimate and frequently-visited web sites in a web browser whitelist will protect systems in those cases where the browser gets redirected to an exploit server under the control of the miscreants. While URL whitelisting can be done with IE in Windows client OSs, doing so is very inconvenient relative to ESC and the whitelisting capabilities in Chrome, Firefox/Seamonkey (via NoScript) and Opera.

    P.S. Since iframes are often used to redirect web browsers to exploit servers, disabling iframes in IE is also an option.
    Rabid Howler Monkey