A Sudden Rise in ActiveX Vulnerabilities – Part 2
In my previous post, I talked about the sudden rise in vulnerabilities affecting ActiveX controls. In this post, I would like to talk a bit about the technology behind ActiveX and various steps that may be taken to prevent attacks.
An ActiveX control is essentially an Object Linking and Embedding (OLE) object. OLE allows objects to be shared using Component Object Model (COM) technology, which is a model that permits software components to communicate with each other. Distributed COM (DCOM) is an extension of COM that allows for the sharing of components over a network. ActiveX technology essentially facilitates the functionality of OLE on the World Wide Web. The controls can run on platforms that support COM or DCOM.
According to Microsoft, ActiveX controls must provide an interface named “IUnknown” to offer functionality and must be self-registering. The IUnknown interface is a general interface that provides pointers to other interfaces of the object through a method called “QueryInterface.” This allows the application that is using the control to access the functionality of the ActiveX control. “Self-registering” means that an ActiveX control must register itself as a control, register all component categories required from the host, and register component categories implemented by the control itself.
ActiveX controls run in containers that are typically client applications such as popular Web browsers. It should be noted that the use of ActiveX controls is not limited to Web browsers; they may be used in a variety of containers such as software development tools and office documents.
ActiveX controls pose various security threats that may compromise the availability, confidentiality, and integrity of a vulnerable computer. An ActiveX control on a computer can be instantiated by arbitrary sites that are aware of the control’s class identifier or CLSID. A CLSID is a unique identifier for a COM object that is stored in the Windows registry. Remote attackers can carry out attacks by enticing a user to visit a malicious Web site that exploits a vulnerable control.
ActiveX controls can run without restrictions unlike Java applications, which are contained within a secured Java Sandbox model. Depending on the implementation of a control, this can provide much needed functionality to non-malicious sites and a dangerous amount of leeway to malicious sites. ActiveX controls are scriptable; therefore, remote Web sites can gain access to supported methods and properties of a control if it is marked safe for initialization or safe for scripting. In addition, many ActiveX controls have been reported to be vulnerable to a variety of security vulnerabilities such as buffer-overflows, denial-of-service, information disclosure, execution of arbitrary applications, etc.
Though vulnerabilities in ActiveX controls can place users at great risk, there are some precautions that can be taken to mitigate the threat of such issues. Users should ensure that the security settings of their client browsers do not allow for scripting of ActiveX controls that are not marked safe for scripting. The browser should prompt for ActiveX controls and deny downloading unsigned ActiveX controls. As a general precaution users should avoid following links to unknown or untrusted sites and run client applications such as Web browsers with the minimal amount of privileges required for functionality. In addition, active scripting should be disabled to prevent the execution of script code and active content in the browser.
Vulnerable users can also set the kill bit on an ActiveX control’s CLSID to prevent the control from running in Internet Explorer. Microsoft has provided details on setting kill bits in Knowledge Base Article 240797.