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:
- IE will determine if this ActiveX Control is kill-bitted or not. If it is, IE will not load the control.
- IE will determine if this ActiveX Control implements IObjectSafety.
- If it does, IE will query through this interface for “Safe for Initialization with data” and “Safe For Scripting”.
- If it does not implement IObjectSafety, IE will look for these properties in the registry under the following implemented categories: {7DD95802-9882-11CF-9FA9-00AA006C42C4} (Safe for Initialization) and {7DD95801-9882-11CF-9FA9-00AA006C42C4}(Safe For Scripting).
Once IE knows these two properties it will follow this logic (under the default configuration):
- IE will load the control to query its IObjectSafety interface.
- If the control does not implement IObjectSafety and does not have the Safe For Initialization or Safe For Scripting properties in the registry, IE will unload this ActiveX Control.
- If the control is Safe for Initialization, IE will instantiate it and IE can receive data through param attributes and the DATA attribute of the object html tag.
- If the control is not Safe for Scripting, IE will not script this control through JavaScript or any other scripting language.
- If this control is Safe for Scripting, IE will allow scripting of this control.
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:
- http://www.milw0rm.com/exploits/4873 : The classid {008B6010-1F3D-11D1-B0C8-00A0C9055D74} has the following properties:
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”.
- · http://www.milw0rm.com/exploits/4874 : The classid {B617B991-A767-4F05-99BA-AC6FCABB102E} has the following properties:
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.