Negative Impacts of VML Vulnerability Workaround

There have been few reports of negative impacts of the two VML workaround scripts I have posted. However, two issues have come up that may be worth pointing out:

  1. Some OEMs apparently ship hard drives with non-standard permissions (ACLs) in various places. I have reports of an unspecified image where the %CommonProgramFiles%\Microsoft Shared\VGX directory has an ACL that has only Everyone:Full Control in it. In the script in the most recent post (http://msinfluentials.com/blogs/jesper/archive/2006/09/22/More-options-on-protecting-against-the-VML-vulnerability-on-a-domain.aspx) I undo the Everyone Deny ACE by removing all permissions from Everyone. On these OEM systems, that means the vgx.dll file now has no permissions at all, and everyone is denied access to the file. To fix that problem, you need to replace the permissions on the directory with the proper permissions. Those are, in SDDL form:
    O:BAG:SYD:ARAI(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)(A;;0x1301bf;;;PU)(A;OICIIO;SDGXGWGR;;;PU)(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;OICIIO;GA;;;CO).

    These permissions are normally inherited from %ProgramFiles%. The only command line way I can find to propagate inherited permissions is to create a security template that specifies and ACL that has only "D:AI" in it and then apply that with secedit. The enableVML.inf template posted in the first post I wrote (http://msinfluentials.com/blogs/jesper/archive/2006/09/19/Block-VML-Zero_2D00_Day-Vuln-on-a-domain.aspx) does exactly that. To apply it with a script, call:
    secedit /configure /db foo.sdb /cfg enableVML.inf /log foo.log /quiet
    This will configure the system silently with that template, which restores the original inherited permissions on the vgx.dll file.
  2. If you put a deny Access Control List Entry (ACE) for Everyone on vgx.dll you will have odd formatting problems with SharePoint. The site simply will not look right. It is unclear why this happens, but the problem only happens if the DLL is registered and it has a deny ACE on it. If the DLL is unregistered, as the startup script does, the problem goes away. In other words, if you use the startup script, this problem goes away.

If you have seen any more problems with any of the work-arounds, I'm sure everyone would love to hear about them and how you solve them.

Published Tue, Sep 26 2006 9:09 AM by jesper
Filed under:

Comments

# Tim Long said on 27 September, 2006 03:07 PM
The sharepoint layout problem happens because the Quick Links bar uses VML to write "Quick Links" vertically up the left hand side of the screen. With VML disabled, the size of the gets messed up and the Quick Links area stretches. IE7 developer toolbar is fantastic for looking at this sort of stuff. After I had used your group policy templates to apply then remove the Deny permission to the VGX.dll file, I found that the patch failed to install. I verified that the Deny had in fact ben removed and that permissions were being inherited, but AU wasn't happy with it for some reason. I just renamed the dll and let SFC put a new copy back there, then the update succeeded. Another one to watch out for if VML has been filtered on ISA server using the script from ISATools.org - this will prevent Outlook RPC-over-HTTP from working until the filters are removed from the relevant publishing rule.
# jesper said on 27 September, 2006 04:50 PM

Tim, this is great info.

I am particularly disturbed by the issue about Outlook RPC/HTTPS. I'll have to dig into that.