Discussion of ActiveX Vulnerabilities

[Symantec]

Discussion of ActiveX Vulnerabilities
<p>Earlier this year I wrote a series of posts that highlighted the rise in vulnerabilities affecting ActiveX controls during 2006. I mentioned that there had been an increase in the number of ActiveX vulnerabilities over the last six years, but more importantly there had been a significant rise in 2006. The first half of 2006 saw the release of 12 vulnerabilities, while there were more than 40 vulnerabilities in the second half.</p>

<p>I also stated that although 2006 saw a significant increase in the number of vulnerabilities in ActiveX controls, this trend would likely continue in 2007 due to the availability of tools and increased interest in ActiveX security in the community. The analysis of the threat landscape during the first half of 2007 supports this prediction. It also appears that issues affecting ActiveX controls make up almost 89% of all vulnerabilities that were reported in browser plug-ins.</p>

<p>According to the <a href="http://www.symantec.com/enterprise/theme.jsp?themeid=threatreport">Symantec <em>Internet Security Threat Report</em></a>, in the first half of 2007 Symantec documented 237 vulnerabilities affecting browser plug-ins. Vulnerabilities affecting ActiveX components comprised 210 of the 237 issues. This represents an increase of 167 more issues; or, over five times the amount of vulnerabilities released during the last half of 2006.</p>

<p>Interestingly (or perhaps more disturbingly) there has also been a rise in proof-of-concept and exploit code that has been made available for ActiveX vulnerabilities released over the past year and a half. It should be noted that the following criteria was used to distinguish between proof-of-concept and exploit code:</p>

<p>• For buffer-overflow issues, programs that lead to arbitrary code execution are considered to be exploits; however, programs that only trigger a crash are considered to be proof-of-concepts.<br />
• For denial-of-service issues, code that triggers a crash is considered to be an exploit.<br />
• For issues such as file overwrites and file deletions, code that successfully exploits the issue is considered to be an exploit.</p>

<p>The following graph illustrates that there has been a large rise in the number of proof-of-concept and exploit code examples along with the vulnerabilities released over time. In the first half of 2006 there were two publicly available ActiveX proof-of-concept examples and one exploit. In the second half of 2006 the number of proof-of-concept examples reached four and the number of exploits reached thirteen. In the first half of 2007 researchers released 27 examples of proof-of-concept code and 64 exploits.</p>

<p><a href="http://www.symantec.com/enterprise/security_response/weblog/upload/2007/10/ActiveX_graph.html" onclick="window.open('http://www.symantec.com/enterprise/security_response/weblog/upload/2007/10/ActiveX_graph.html','popup','width=592,height=239, scrollbars=no,resizable=no,toolbar=no,directories= no,location=no,menubar=no,status=no,left=0,top=0') ; return false"><img src="http://www.symantec.com/enterprise/security_response/weblog/upload/2007/10/ActiveX_graph_sml.jpeg" width="370" height="149" /></a></p>

<p><strong>Figure 1. Vulnerabilities and proof-of-concept code affecting ActiveX components</strong><br />
(Click for larger image)</p>

<p>This trend clearly indicates an increase in the number of publicly available exploits and clearly shows that it is relatively trivial for attackers to exploit these issues. In addition, it should be noted that due to the availability of a large number of proof-of-concept samples and exploits for these issues, it is relatively simple to develop exploits for new vulnerabilities by referring to and modifying existing examples. Furthermore, attackers also have a large number of potential targets due to the prevalence of a vast amount of vulnerabilities in ActiveX controls.<br />
Vulnerabilities affecting ActiveX controls have been exploited in the wild as well. In the past year and a half the following are some of the issues that were observed to be exploited by attackers in the wild:<br />
• <a href="http://www.securityfocus.com/bid/20915">Microsoft XML Core Service XMLHTTP ActiveX Control Remote Code Execution Vulnerability</a>, <br />
• <a href="http://www.securityfocus.com/bid/21060">WinZip WZFileView.FileViewCtrl.61 ActiveX Control Multiple Remote Code Execution Vulnerabilities</a>, <br />
• <a href="http://www.securityfocus.com/bid/23674">IncrediMail IMMenuShellExt ActiveX Control Remote Buffer Overflow Vulnerability</a>, <br />
• <a href="http://www.securityfocus.com/bid/24355">Yahoo! Messenger Webcam Viewer ActiveX Control Buffer Overflow Vulnerability</a><br />
<br />
Also, the MPack malware kit automatically exploits various ActiveX vulnerabilities. These developments in the threat landscape further signify the need for users to be vigilant against ActiveX threats and ensure that adequate safety measures are taken. Users should ensure that the security settings of their Web 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, using 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.</p>

<p>Users with vulnerable systems 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 <a href="http://support.microsoft.com/kb/240797">Knowledge Base Article 240797</a>.</p>

<p>In addition to the precautions outlined above, users of Microsoft’s newest operating system should be sure to fully utilize the new security features present in Internet Explorer 7 (IE 7) with Microsoft Windows Vista. In previous versions of Windows, Internet Explorer was able to launch an ActiveX control if the control was marked "safe for scripting." In IE 7 with Windows Vista, ActiveX controls that are executed in the "Internet" or "Restricted" zone are prevented from being called through Internet Explorer. IE 7 has the "Allow Previously Unused ActiveX Controls to Run Without Prompting" setting disabled by default. Vista users or administrators must approve an ActiveX control before it is allowed to be launched with Internet Explorer. The default settings of Vista only allow users with local administrator rights to be able to install ActiveX controls.</p>

<p><em><strong>Some of the default settings in IE 7 are outlined below:</strong></em></p>

<p><strong>Automatic prompting for ActiveX controls</strong></p>

<p>This setting has been enabled by default in the "Local Intranet" zone. It prompts users with a pop-up dialog box when a site attempts to install an ActiveX control. In previous versions of Internet Explorer an information bar was used instead of a pop-up dialog box.</p>

<p><strong>Run ActiveX controls and plug-ins</strong></p>

<p>The execution of ActiveX controls can be completely disabled by enabling this setting in all zones. By default, Internet Explorer only enables this setting for the "Restricted" zone because disabling ActiveX controls can severely limit functionality of some Web sites.</p>

<p><strong>Script ActiveX controls marked safe for scripting</strong></p>

<p>This setting allows users to disable scripting for ActiveX controls that were previously marked "safe for scripting". By default, Internet Explorer only enables this setting for the Restricted zone. This setting should be used as a last resort to protect computers and can severely limit functionality of some Web sites. It could be useful to prevent successful exploitation of attacks with no known defense or mitigation.</p>

<p><em><strong>The following are some other security features of IE 7 with Windows Vista that should be noted:</strong></em></p>

<p><strong>ActiveX installer service in Windows Vista</strong></p>

<p>The ActiveX installer service in Windows Vista can be used by administrators to allow non-administrative users to install ActiveX controls. Administrators can specify the hosts that users can install ActiveX controls from using group policy settings. More information can be found here: <a href="http://blogs.msdn.com/uac/archive/2006/09/13/752248.aspx">http://blogs.msdn.com/uac/archive/2006/09/13/752248.aspx</a></p>

<p><strong>Protected mode</strong></p>

<p>IE 7.0 on Windows Vista runs in protected mode by default. In Windows Vista, mandatory integrity controls (MICs) are assigned to all applications, users, and objects. By running in protected mode the browser executes with a low MIC. This prevents add-ons and downloaded content, which run with medium integrity from making changes to system files or the Windows Registry. This is meant to limit the consequences of a successful attack. It should be noted that protected mode provides limited protection and only applies if the content was downloaded without a user’s permission. If a user is tricked into executing active content, such as the installation of an ActiveX control, the content will be executed with high integrity or elevated privileges. More information can be found here:<br />
<a href="http://www.microsoft.com/windows/products/windowsvista/features/details/ie7protectedmode.mspx">http://www.microsoft.com/windows/products/windowsvista/features/details/ie7protectedmode.mspx</a></p>

<p><strong>Internet Explorer add-on management</strong></p>

<p>IE 7 and Internet Explorer running on Windows XP SP2 allow users to easily manage browser add-ons including ActiveX controls. Users can enable or disable unnecessary add-ons by accessing "Tools -> Manage Add-ons -> Enable or Disable Add-ons" from the browser’s menu options. Users can also choose to update add-ons using this option. It should be noted that disabling an add-on only prevents Internet Explorer from using it and does not remove the add-on from the computer. More information can be found here:<br />
<a href="http://www.microsoft.com/windowsxp/using/web/sp2_addonmanager.mspx ">http://www.microsoft.com/windowsxp/using/web/sp2_addonmanager.mspx </a></p>

<p>Finally, in addition to the precautions that may be taken by an end user, network administrators can also take steps towards securing computers by using group policies to control access to the sources of ActiveX controls. More information can be found here: <a href="http://www.microsoft.com/technet/technetmag/issues/2005/05/GroupPolicy/default.aspx">http://www.microsoft.com/technet/technetmag/issues/2005/05/GroupPolicy/default.aspx</a><br />
<br />
In Windows Vista, administrators can enable the ActiveX installer service that can be used with group policy templates and a safelist of accepted locations from where users can obtain and install safe ActiveX controls. More information can be found here: <a href="http://blogs.msdn.com/uac/archive/2006/06/14/631416.aspx">http://blogs.msdn.com/uac/archive/2006/06/14/631416.aspx</a></p>
http://www.symantec.com/enterprise/security_response/weblog/2007/11/discussion_of_activex_vulnerab.html
http://www.symantec.com/enterprise/security_response/weblog/2007/11/discussion_of_activex_vulnerab.html
Tue, 13 Nov 2007 05:00:00 -0800