In early January you may have read posts on security distribution lists regarding two ActiveX Controls released by Microsoft. We have investigated those controls and fortunately, they are not exploitable since IE does not treat them as being safe. We wanted to give you some background on how to evaluate whether a potential vulnerability found in an ActiveX control is an exploitable condition in Internet Explorer.
Each time IE finds an embedded ActiveX control in an HTML web page, IE will perform the following checks to verify if it is safe for initialization and scripting:
Once IE knows these two properties it will follow this logic (under the default configuration):
If a malicious web page tries to take advantage of any of these controls and its methods, IE will NOT script them due to the classid’s properties (“Safe for Initialization” and “Safe for Scripting”). The attacked user will see IE’s gold bar since IE treats them as unsafe, and scripting them is a requirement for the successful exploitation of these controls.
In general, IE (in the Internet Zone) will not script and/or load this type of classid as mentioned in this article: “INFO: How Internet Explorer Determines If ActiveX Controls Are Safe” http://support.microsoft.com/kb/q216434/
Analysis about the recent posts can be found below:
Clsid: {008B6010-1F3D-11D1-B0C8-00A0C9055D74} Progid: VisualFoxpro.Application.6 Binary Path: C:\Program Files\Microsoft Visual Studio\Vfp98\vfp6.exe Implements IObjectSafety: False Safe For Initialization: False Safe For Scripting: False KillBitted: False
With the installation of Visual Fox Pro 6 this classid will automatically be available in the system. Since it does not implement IObjectSafety, IE will determine whether the file is safe to use via some properties on the registry for this control such as “Safe for Initialization” and “Safe for Scripting”, in this case “false”.
Clsid: {B617B991-A767-4F05-99BA-AC6FCABB102E} Binary Path: C:\Windows\System32\RICHTX32.OCX Implements IObjectSafety: True Safe For Initialization (IObjectSafety): True Safe For Scripting (IObjectSafety): False Safe For Initialization (Registry): False Safe For Scripting (Registry): False KillBitted: False
Even though this control implements IObjectSafety, IE will not trust it since it is not marked as “Safe for Scripting”. “Safe for Scripting” is required in order to trigger the vulnerability: writing files via SaveFile() method. Since IE will not script it, there is no vulnerability through IE in its default secure configuration.
We have attached source code to this blog post to list the various properties of ActiveX controls. This tool was used to generate the output above dumping the ActiveX properties of the milw0rm posts.
- Security Vulnerability Research & Defense Bloggers
*Postings are provided "AS IS" with no warranties, and confers no rights.*
7/29/09 Update: Fixed a typo in the Safe for Scripting CLSID. Thanks to Leo Davidson for bringing this to our attention.