Last week, the Zero Day Initiative (ZDI) decided that Microsoft has had enough time within its coordinated vulnerability disclosure program to fix a vulnerability in Internet Explorer 8.

This use-after-free vulnerability in Microsoft Internet Explorer 8 allows remote attackers to execute arbitrary code via crafted JavaScript code that interacts improperly with a CollectGarbage function call on a CMarkup object allocated by the CMarkup::CreateInitialMarkup function.

A Belgian researcher found a problem in Internet Explorer 8, last year. He sold the information via the Zero Day Initiative to TippingPoint, who reported the vulnerability to Microsoft on October 11, 2013. On May 8, 2014, the Zero Day Initiative warned Microsoft to come up with a solution. A mere two weeks later, on May 21, 2014, the Zero Day Initiative made the vulnerability public.

Apparently, there is a difference between responsible vulnerability disclosure and coordinated vulnerability disclosure… I don’t know, yet, which one serves me better.

The impact

Affected systems

The vulnerability only impacts Microsoft Internet Explorer 8.

This fact, plus the fact that the vulnerability is not actively exploited in the field, makes it very plausible that this vulnerability ended up at the bottom of the pile of stuff to fix in Microsoft Internet Explorer. In fact, I will even state that admins confronted with exploits, have themselves more than Microsoft to blame.

• Internet Explorer 11 is the default browser for Windows 8.1. This version of Internet Explorer is not vulnerable.
• Internet Explorer 10 is the default browser for Windows 8. This version of Internet Explorer is not vulnerable.
• While Internet Explorer 8 was the default version of Internet Explorer for Windows 7, but Microsoft has, since RTM, made several versions of Internet Explorer available as Important updates. Only when Windows 7’s Internet Explorer has not been updated, its Internet Explorer 8 installation is vulnerable.
      
       Note:
       Windows 7 without Service Pack 1 is no longer supported by Microsoft.
       However, this Service Pack did not contain an updated Internet Explorer.
      
• Internet Explorer 7 is the default browser in Windows Vista. The most recent version of Internet Explorer for Windows Vista, however, is Internet Explorer 9.
• Internet Explorer 6 was the default browser for Windows XP. Internet Explorer 8 is the most recent version for Windows XP, but Windows XP is out of support.

Code execution

An attacker who successfully exploited this Internet Explorer vulnerability could gain the same user rights as the current user. Just like with the Internet Explorer ‘WontFix’ bug last month (CVE-2014-1776), in organizations, implementing Windows with Least Administrative Privilege is the best practice and the standard. It should come as no surprise this principle is extensively covered in all Windows-oriented Microsoft exams.

Again, admins confronted with exploits in environments without this best practice applied, have themselves more than Microsoft to blame.

Workarounds

Microsoft has been able to reproduce the undesirable Internet Explorer behavior and the ability to be able to run code as the logged on user.

For admins that fins themselves stuck with Internet Explorer 8 (for instance, on Windows Server 2003 (R2)-based Terminal Services), Microsoft has formulated a couple of workarounds that make the vulnerability in Internet Explorer 8 non-exploitable:

• Set Internet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones.
• Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.
• Install and configure the Enhanced Mitigation Experience Toolkit (EMET) to work with Internet Explorer.

While we’re waiting for Microsoft to fix this vulnerability in Internet Explorer (except for Windows XP), the workarounds can be applied:

Change Internet Explorer zone’s settings

All of these actions can be performed using Group Policy and Group Policy Preferences.
You can find these as part of the User Configuration, Preferences, Control Panel Settings, Internet Settings of a Group Policy Object (GPO). Simply add settings for Internet Explorer 8 and 9 or change any settings you might have in place.

Setting the Internet Zone security level to High can be done on the Security tab:

Alternatively, you can leave the default Medium-high settings for the Internet Zone, and change the Active Scripting settings using the Custom Level… button. Press F8 first to not configure all these settings for Internet Explorer installations (unless you want to). Then scroll down to Automatic prompting for ActiveX controls, press F6 and configure this specific setting to Enable:

Alternatively, you can disable ActiveX altogether, by not configuring the Automatic prompting for ActiveX controls setting (press F7 to not apply the setting) and configuring the Run ActiveX controls and plug-ins. Again, Press F6 to enable the setting, then configure it as Disable:

When done press OK to close the Internet Zone properties. When you’ve chosen to change the specific ActiveX settings, also apply them to the Local Intranet Zone. Press OK in the Internet Explorer 8 and 9 Properties screen and close the Group Policy Management Editor screen to finish the Group Policy Object. Then, apply the object to users running Internet Explorer 8.

Install and configure EMET

The above three strategies will secure the Internet Explorer 8 installations within an organization, but are not very user-friendly. The best way to deal with vulnerabilities like these, is to install and configure the Enhanced Mitigation Experience Toolkit (EMET). You can use the Software Installation capabilities of Group Policy to deploy it. Not only, will it protect from exploits of this particular vulnerability in this particular version of Internet Explorer, but most vulnerabilities in all supported versions of Internet Explorer.

Concluding

Internet Explorer 8 is five years old. Admins have had multiple chances to get rid of it and other ancient technology.

Further reading

CVE-2014-1770 
Vulnerability Note VU#239151
ZDI-14-140 (0Day) Microsoft Internet Explorer CMarkup Use-After-Free Remote Code Execution Vulnerability 
Microsoft IE Zero-Day Flaw Could Leave Millions at Risk   
Microsoft Intentionally Failing to Patch Critical Vulnerability in Explorer IE 8 
New Internet Explorer Zero-Day Vulnerability Publicly Disclosed; Identified in October 2013  
Microsoft warns of major Internet Explorer bug; no fix for Windows XP