Telling when ActiveX vulnerabilities are exploitable in Internet Explorer

Feb 6, 2008 12:38 GMT  ·  By

Microsoft's Internet Explorer is without a doubt the main vector of attacks, when it comes down to web-based threats. Its ubiquity, as well as its intimate integration into the Windows platform, makes it an excellent avenue for attacks. With IE6, Microsoft has gained an ill reputation for failing dramatically to protect end users. From IE6, which undoubtedly is an apex of insecurity compared to alternative browsers, the Redmond company moved to Windows Vista and Internet Explorer 7 under User Account Control, virtually cutting the browser from the critical areas of the operating system. Web-based attacks coming via IE7 in Protect Mode will not be able to write themselves to disk without specific user permission, because the browser runs with the very least possible privileges.

But when talking about attacks via Internet Explorer, it is almost impossible not to mention the exploitation of the ActiveX controls mechanism. Microsoft revealed that for an ActiveX control to be exploitable in Internet Explorer, the browser has to threat it like it is safe. In this manner, some of the vulnerabilities associated with ActiveX controls are not exploitable due to the browser's restrictions.

"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 {7DD95802-9882-11CF-9FA9-00AA006C42C4}(Safe For Scripting)," revealed a member of the Security Vulnerability Research & Defense team.

In the default configuration, IE will move on to load the control in order to query its IObjectSafety interface, but only in the context of the two properties already mentioned. At this stage, the browser will immediately unload the control, if it does not come across the following registry properties: Safe For Initialization or Safe For Scripting, combined with the lack of implementation of IObjectSafety.

"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," added the member of the Security Vulnerability Research & Defense team.