In my previous post,I talked about the sudden rise in vulnerabilities affecting ActiveXcontrols. In this post, I would like to talk a bit about the technologybehind 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 ObjectModel (COM) technology, which is a model that permits softwarecomponents to communicate with each other. Distributed COM (DCOM) is anextension of COM that allows for the sharing of components over anetwork. ActiveX technology essentially facilitates the functionalityof OLE on the World Wide Web. The controls can run on platforms thatsupport COM or DCOM.
According to Microsoft, ActiveX controls must provide an interface named “IUnknown”to offer functionality and must be self-registering. The IUnknowninterface is a general interface that provides pointers to otherinterfaces of the object through a method called “QueryInterface.” Thisallows the application that is using the control to access thefunctionality of the ActiveX control. “Self-registering” means that anActiveX control must register itself as a control, register allcomponent categories required from the host, and register componentcategories implemented by the control itself.
ActiveX controls run in containers that are typically clientapplications such as popular Web browsers. It should be noted that theuse of ActiveX controls is not limited to Web browsers; they may beused in a variety of containers such as software development tools andoffice documents.
ActiveX controls pose various security threats that may compromisethe availability, confidentiality, and integrity of a vulnerablecomputer. An ActiveX control on a computer can be instantiated byarbitrary sites that are aware of the control’s class identifier orCLSID. A CLSID is a unique identifier for a COM object that is storedin the Windows registry. Remote attackers can carry out attacks byenticing a user to visit a malicious Web site that exploits avulnerable control.
ActiveX controls can run without restrictions unlike Javaapplications, which are contained within a secured Java Sandbox model.Depending on the implementation of a control, this can provide muchneeded functionality to non-malicious sites and a dangerous amount ofleeway to malicious sites. ActiveX controls are scriptable; therefore,remote Web sites can gain access to supported methods and properties ofa control if it is marked safe for initialization or safe forscripting. In addition, many ActiveX controls have been reported to bevulnerable to a variety of security vulnerabilities such asbuffer-overflows, denial-of-service, information disclosure, executionof arbitrary applications, etc.
Though vulnerabilities in ActiveX controls can place users at greatrisk, there are some precautions that can be taken to mitigate thethreat of such issues. Users should ensure that the security settingsof their client browsers do not allow for scripting of ActiveX controlsthat are not marked safe for scripting. The browser should prompt forActiveX controls and deny downloading unsigned ActiveX controls. As ageneral precaution users should avoid following links to unknown oruntrusted sites and run client applications such as Web browsers withthe minimal amount of privileges required for functionality. Inaddition, active scripting should be disabled to prevent the executionof script code and active content in the browser.
Vulnerable users can also set the kill bit on an ActiveX control’sCLSID to prevent the control from running in Internet Explorer.Microsoft has provided details on setting kill bits in Knowledge Base Article 240797.