Internet Explorer VML Zero-Day Mitigation

Sunbelt’s recent Vector Markup Language (VML) vulnerability discovery has drawn some attention here on the blogs, and rightly so. The impact of the vulnerability is fairly significant and there are reports that malicious sites are exploiting the vulnerability to install malicious code of all sorts.

For those without perimeter/endpoint defenses to identify the exploit and those seeking additional assurances that the issue can be effectively blocked, I’d like to note some workarounds that I’ve found effective. The vulnerable component in this instance is vgx.dll. Microsoft has proposed three workarounds in Security Advisory 925568 that appear to be effective in blocking the attack, and another aimed at mitigating the attack.
Microsoft notes that reading e-mail in plain text is a mitigator against e-mail based attacks, but the attacks seen at this time are not e-mail based, to the best of my knowledge. You may disable access to vgx.dll by either un-registering it or blocking access with file system access control lists. Microsoft also suggests users of Windows XP SP2 disable binary and script behaviors within Internet Explorer. All of these workarounds are effective, and you should apply them if possible.

Some important guidance, however, is absent from the Microsoft advisory, and I’d like to raise it here.

[UPDATE: In additional testing, I discovered that Microsoft's proposed workaround of un-registering the vulnerable vgx.dll appears effective for users of Windows 2000 Service Pack 4. The security advisory posted by Microsoft indicates that this guidance applies only to users of Windows XP and Windows Server 2003, and by implication, that it is not effective for Windows 2000 users. Microsoft may not have tested this workaround against Windows 2000, or the company may have had concerns about effectiveness; an explanation for the apparent omission cannot be inferred from the advisory. Accordingly, I'd recommend testing this workaround well before deploying it on Windows 2000 systems, but it may yet be a viable option for you.]

We’ve also confirmed that Windows XP Service Pack 2 users can enable system-wide enforcement of software-enforced DEP to effectively block the in-the-wild exploits of this vulnerability, while retaining the ability to use the targeted Vector Markup Language (VML) functionality. Microsoft Knowledge Base Article 875352 describes how to change DEP policy using either the System control panel applet or the boot.ini file. Either method requires a system reboot to take effect.

To deploy this workaround, ensure your local DEP policy is set to “OptOut” (in boot.ini) or “Turn on DEP for all programs and services except those I select” (in the System Control Panel applet) and that the applet does NOT list Internet Explorer as exempt from DEP protection. If this setting is used, all systems with the DEP capability are protected, including those without hardware support for the No Execute/Execute Disable bits.

Also worth mentioning is that the current in-the-wild exploits attempt system-wide software installations, as do most zero-day exploits for such vulnerabilities. If your browser is not running under an account with administrative privileges, this will not succeed. The most effective way to do this is for users to log on interactively with accounts running as Limited Users, rather than members of the privileged Power Users or Administrators groups. Michael Howard wrote an MSDN article that describes an alternative way to run high-risk applications like browsers without administrative privileges if you require a privileged interactive logon for some reason.

[Update: A software glitch during editing caused this post to appear cut off to some readers. That's been fixed.]

Share
  • Pingback: A geek's diary

  • luss

    IE7 is not vulnerable

  • Nim7

    I would ask for some clarification, it appears to me that IE7 IS vulnerable, as it uses the same .dll as earlier iterations of the browser. I tested my IE7 browser on ZERT’s site, and it came back as vulnerable, as did the Vista RC1 64 bit build with IE7.

    Commenting that IE7 is not vulnerable is not enough proof to me that it is not. Please explain further or retract it.

  • Pingback: Will Murray's Blog