Mitigate the Image Uploader Vulnerabilities

The big security news this week is the six vulnerabilities found in various image uploader ActiveX controls. In case you haven't seen the news, there are exploits available publicly for remote vulnerabilities in five different ActiveX controls. US-CERT is offering the, relatively unhelpful, advice that users disable all ActiveX controls in their browser. Doing so would have the effect of disabling a lot of things, notably virtually every corporate expense reporting application. Your users will probably have a thing or two to say about that. You can mitigate that by adding all the sites users will ever need to the Trusted Sites zone, but if you haven't done that in the 10 years or so that you have had the option, you probably will not do it now.

That means you, like me, are probably looking for other options. Tom Liston, of SANS/IntelGuardians, created an application to set the kill bit on the affected controls. It is a nice little tool. However, his tool is local only, the source is not available, it is not digitally signed but instead uses an MD5 signature for source verification (standard on Linux, but not on Windows), and it uses a non-standard way of defining the control to modify. What is more disturbing about that tool, however, is that it really does not work the way it should to maintain stability. First, instead of specifying the correct set of permissions when it opens the registry, it uses the MAXIMUM_ALLOWED flag. That flag will cause the call to succeed even if you do not have sufficient permission to actually write to the registry. It is considered highly inadvisable to use MAXIMUM_ALLOWED at all. Second, the tool fails to check whether you have appropriate permissions to edit the registry, and appears to succeed even if you do not. In other words, on Windows Vista, if you are not an administrator but execute the tool, it will appear to have protected you when in fact nothing was ever done. The changes in fact got virtualized and written into the registry virtual store. It does not contain a Vista manifest to indicate that it must be run as an Administrator. Third, it fails to preserve any existing compatibility flags when you set the killbit. This can also cause severe damage to the control, and is against the best practices set forth in Microsoft's Kill bit FAQ. The compatibility flags value serves a whole lot more purposes than just as a kill bit, as documented on the Microsoft Developer Network. For all these reasons I, unfortunately, recommend against using the SANS tool to mitigate this problem.

To handle the problem without having to risk the problems outlined above, and in a way which is more scalable to an enterprise environment, I decided to dust off the old SlayOCX vbscript that I wrote for the VML vulnerability about 18 months ago. That script sets the kill bit on any ActiveX control, and can also reverse the changes. It also toggles only the kill bit. Virtually all other tools that set kill bits will also cause the loss of any other compatibility flags, possibly causing long-term damage. According to the just published kill bit FAQ, this is important to avoid. The SlayOCX.vbs script does not do that.

We can quite easily tie the SlayOCX.vbs script into a startup script, and then link the startup script to a GPO. That will effectively disable the controls on all managed systems. First, we need a custom script with all the ActiveX controls enumerated:

<begin script>

REM Facebook
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 5C6698D9-7BE4-4122-8EC5-291D84DBD4A0 -l

REM Yahoo MediaGrid
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 22FD7C0A-850C-4A53-9821-0B0915C96139 -l

REM Yahoo DataGrid
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 5F810AFC-BB5F-4416-BE63-E01DD117BD6C -l


REM Aurigma controls from http://www.kb.cert.org/vuls/id/776931
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 104B0A37-AB99-4F06-8032-8BBDC3B77DDB -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 17D667BA-5675-4AAB-9221-08B9379384D4 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 48DD0448-9209-4F81-9F6D-D83562940134 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 55027008-315F-4F45-BBC3-8BE119764741 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 6E5E167B-1566-4316-B27F-0DDAB3484CF7 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k A18962F6-E6ED-40B1-97C9-1FB36F38BFA8 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k AE2B937E-EA7D-4A8D-888C-B68D7F72A3C4 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k AE6C4705-0F11-4ACB-BDD4-37F138BEF289 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k B85537E9-2D9C-400A-BC92-B04F4D9FF17D -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k BA162249-F2C5-4851-8ADC-FC58CB424243 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k D1D98C0F-A339-42AB-BD5F-EA0FF5D0E65F -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k D1EA8D3D-F511-4388-B754-4A0CC14A4778 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k F1F51698-7B63-4394-8743-1F4CF1853DE1 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k F89EF74A-956B-4BD3-A066-4F23DF891982 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k FB90BA05-66E6-4c56-BCD3-D65B0F7EBA39 -l

</end script>

 Next, we can follow the directions in the original post to configure a logon script:

  1. Copy the script above (everything between the begin and end tags) and paste it into a new text document. Save the document as "NoPicturesPlease.cmd". Alternatively, just download and expand the SlayOCX_v1.1.zip file attached to this post.
  2. Open NoPicturesPlease.cmd in Notepad, hit CTRL+H and do a global find replace on "<your domain>" with the name of your domain.
  3. Copy the NoPicturesPlease.cmd file and SlayOCX.vbs to \\<your domain>\sysvol\<your domain>\scripts. where you replace "<your domain>" with the full DNS name of your domain.
  4. Open the GPMC (if you do not have the Group Policy Management Console, you need to get it. Strictly speaking you can manage GPOs without it, but you really don't want to)
  5. Right-click the domain or OU where you want to link the GPO - you may as well do it at the domain level - and select "Create and Link a GPO Here..." Name your new GPO "NoPicturesPlease"
  6. Right-click the GPO NoPicturesPlease and select "Edit..."
  7. Expand "Computer Configuration:Windows Settings" and click on "Scripts (Startup/Shutdown).
  8. Double-click "Startup" in the right-hand pane
  9. Click "Add..."
  10. Browse to \\<your domain>\sysvol\<your domain>\scripts and select "NoPicturesPlease.cmd". Click "Open"
  11. Click "OK" again.
  12. Close the GPO editor and go back to the GPMC
  13. In the "Security Filtering" pane remove "Authenticated Users" and click Add...
  14. In the text box called "Enter the object name..." type "Domain Computers" or some other relevant group that you want to apply the policy to. Click OK.

When the computers next restart they will automatically apply the mitigation and kill bit all the relevant ActiveX controls. If any given ActiveX control does not exist on a particular computer nothing will be done to it. The script will also create a log file in the root of the boot volume, called "SlayOCX.log". By monitoring that log file you can tell how much the mitigation has modified the computers as well. If it finds any of the ActiveX controls you also have a good indication that people are surfing social networking sites at work, just in case you worry about such things.

If you want to ever undo the mitigation you can modify NoPicturesPlease.cmd to use the -r switch instead of the -k switch.

Attachment: SlayOCX_v1.1.zip
Published Wed, Feb 6 2008 11:07 AM by jesper
Filed under: , ,

Comments

# Aaron Margosis said on 10 February, 2008 08:15 AM

I think it's more accurate to call it a "startup script" rather than a "logon script":  logon scripts run in the security context of the user logging on, while startup scripts run as System.  You need the latter here, since users can't set those kill bits.  (The instructions you wrote indicate a "startup script", which is correct, so it's just about terminology.)

# jesper said on 10 February, 2008 12:19 PM

Of course Aaron. I meant to say startup script. Fixing now.

# Roshan James said on 14 February, 2008 10:39 AM

Sorry for a comment that is a little out of place. What brings me to your website is your article about ACLs and such.

www.microsoft.com/.../sm1105.mspx

There you say strange things like this:

"Power Users are administrators who simply have not made themselves administrators yet.

You cannot remove the ACLs on the file system, or even the registry, and prevent that. Power Users are ingrained in the operating system, and they have sufficient privileges to escalate to an administrator fairly easily."

At the risk of sounding obnoxious I must say, I am baffled by how anyone is expected to know this. Is there some place where this is all written down is a accessible way? Maybe a lattice of builtin users and a lattice of ACL permissions?

I am try to decipher the ACL format of icacls, at it is simply so hard to find any readable and reliable information about this. Would you know where I might find some?

I see from your technet webpage that you left the company. Congratulations.

# Anthony Perkins said on 15 February, 2008 01:04 AM

Jesper, thanks for your work on this.