Earlier this year I wrote a series of poststhat highlighted the rise in vulnerabilities affecting ActiveX controlsduring 2006. I mentioned that there had been an increase in the numberof ActiveX vulnerabilities over the last six years, but moreimportantly there had been a significant rise in 2006. The first halfof 2006 saw the release of 12 vulnerabilities, while there were morethan 40 vulnerabilities in the second half.
I also stated that although 2006 saw a significant increase in thenumber of vulnerabilities in ActiveX controls, this trend would likelycontinue in 2007 due to the availability of tools and increasedinterest in ActiveX security in the community. The analysis of thethreat landscape during the first half of 2007 supports thisprediction. It also appears that issues affecting ActiveX controls makeup almost 89% of all vulnerabilities that were reported in browserplug-ins.
According to the Symantec Internet Security Threat Report,in the first half of 2007 Symantec documented 237 vulnerabilitiesaffecting browser plug-ins. Vulnerabilities affecting ActiveXcomponents comprised 210 of the 237 issues. This represents an increaseof 167 more issues; or, over five times the amount of vulnerabilitiesreleased during the last half of 2006.
Interestingly (or perhaps more disturbingly) there has also been arise in proof-of-concept and exploit code that has been made availablefor ActiveX vulnerabilities released over the past year and a half. Itshould be noted that the following criteria was used to distinguishbetween proof-of-concept and exploit code:
• For buffer-overflow issues, programs that lead to arbitrary codeexecution are considered to be exploits; however, programs that onlytrigger a crash are considered to be proof-of-concepts.
• For denial-of-service issues, code that triggers a crash is considered to be an exploit.
• For issues such as file overwrites and file deletions, code thatsuccessfully exploits the issue is considered to be an exploit.
The following graph illustrates that there has been a large rise inthe number of proof-of-concept and exploit code examples along with thevulnerabilities released over time. In the first half of 2006 therewere two publicly available ActiveX proof-of-concept examples and oneexploit. In the second half of 2006 the number of proof-of-conceptexamples reached four and the number of exploits reached thirteen. Inthe first half of 2007 researchers released 27 examples ofproof-of-concept code and 64 exploits.
Figure 1. Vulnerabilities and proof-of-concept code affecting ActiveX components
(Click for larger image)
This trend clearly indicates an increase in the number of publiclyavailable exploits and clearly shows that it is relatively trivial forattackers to exploit these issues. In addition, it should be noted thatdue to the availability of a large number of proof-of-concept samplesand exploits for these issues, it is relatively simple to developexploits for new vulnerabilities by referring to and modifying existingexamples. Furthermore, attackers also have a large number of potentialtargets due to the prevalence of a vast amount of vulnerabilities inActiveX controls.
Vulnerabilities affecting ActiveX controls have been exploited in thewild as well. In the past year and a half the following are some of theissues that were observed to be exploited by attackers in the wild:
• Microsoft XML Core Service XMLHTTP ActiveX Control Remote Code Execution Vulnerability,
• WinZip WZFileView.FileViewCtrl.61 ActiveX Control Multiple Remote Code Execution Vulnerabilities,
• IncrediMail IMMenuShellExt ActiveX Control Remote Buffer Overflow Vulnerability,
• Yahoo! Messenger Webcam Viewer ActiveX Control Buffer Overflow Vulnerability
Also, the MPack malware kit automatically exploits various ActiveXvulnerabilities. These developments in the threat landscape furthersignify the need for users to be vigilant against ActiveX threats andensure that adequate safety measures are taken. Users should ensurethat the security settings of their Web browsers do not allow forscripting of ActiveX controls that are not marked safe for scripting.The browser should prompt for ActiveX controls and deny downloadingunsigned ActiveX controls. As a general precaution users should avoidfollowing links to unknown or untrusted sites and run clientapplications, such as Web browsers, using the minimal amount ofprivileges required for functionality. In addition, active scriptingshould be disabled to prevent the execution of script code and activecontent in the browser.
Users with vulnerable systems can also set the kill bit on anActiveX control’s CLSID to prevent the control from running in InternetExplorer. Microsoft has provided details on setting kill bits in Knowledge Base Article 240797.
In addition to the precautions outlined above, users of Microsoft’snewest operating system should be sure to fully utilize the newsecurity features present in Internet Explorer 7 (IE 7) with MicrosoftWindows Vista. In previous versions of Windows, Internet Explorer wasable to launch an ActiveX control if the control was marked "safe forscripting." In IE 7 with Windows Vista, ActiveX controls that areexecuted in the "Internet" or "Restricted" zone are prevented frombeing called through Internet Explorer. IE 7 has the "Allow PreviouslyUnused ActiveX Controls to Run Without Prompting" setting disabled bydefault. Vista users or administrators must approve an ActiveX controlbefore it is allowed to be launched with Internet Explorer. The defaultsettings of Vista only allow users with local administrator rights tobe able to install ActiveX controls.
Some of the default settings in IE 7 are outlined below:
Automatic prompting for ActiveX controls
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 toinstall an ActiveX control. In previous versions of Internet Exploreran information bar was used instead of a pop-up dialog box.
Run ActiveX controls and plug-ins
The execution of ActiveX controls can be completely disabled byenabling this setting in all zones. By default, Internet Explorer onlyenables this setting for the "Restricted" zone because disablingActiveX controls can severely limit functionality of some Web sites.
Script ActiveX controls marked safe for scripting
This setting allows users to disable scripting for ActiveX controlsthat were previously marked "safe for scripting". By default, InternetExplorer only enables this setting for the Restricted zone. Thissetting should be used as a last resort to protect computers and canseverely limit functionality of some Web sites. It could be useful toprevent successful exploitation of attacks with no known defense ormitigation.
The following are some other security features of IE 7 with Windows Vista that should be noted:
ActiveX installer service in Windows Vista
The ActiveX installer service in Windows Vista can be used byadministrators to allow non-administrative users to install ActiveXcontrols. Administrators can specify the hosts that users can installActiveX controls from using group policy settings. More information canbe found here: http://blogs.msdn.com/uac/archive/2006/09/13/752248.aspx
Protected mode
IE 7.0 on Windows Vista runs in protected mode by default. InWindows Vista, mandatory integrity controls (MICs) are assigned to allapplications, users, and objects. By running in protected mode thebrowser executes with a low MIC. This prevents add-ons and downloadedcontent, which run with medium integrity from making changes to systemfiles or the Windows Registry. This is meant to limit the consequencesof a successful attack. It should be noted that protected mode provideslimited protection and only applies if the content was downloadedwithout a user’s permission. If a user is tricked into executing activecontent, such as the installation of an ActiveX control, the contentwill be executed with high integrity or elevated privileges. Moreinformation can be found here:
http://www.microsoft.com/windows/products/windowsvista/features/details/ie7protectedmode.mspx
Internet Explorer add-on management
IE 7 and Internet Explorer running on Windows XP SP2 allow users toeasily manage browser add-ons including ActiveX controls. Users canenable or disable unnecessary add-ons by accessing "Tools -> ManageAdd-ons -> Enable or Disable Add-ons" from the browser’s menuoptions. Users can also choose to update add-ons using this option. Itshould be noted that disabling an add-on only prevents InternetExplorer from using it and does not remove the add-on from thecomputer. More information can be found here:
http://www.microsoft.com/windowsxp/using/web/sp2_addonmanager.mspx
Finally, in addition to the precautions that may be taken by an enduser, network administrators can also take steps towards securingcomputers by using group policies to control access to the sources ofActiveX controls. More information can be found here: http://www.microsoft.com/technet/technetmag/issues/2005/05/GroupPolicy/default.aspx
In Windows Vista, administrators can enable the ActiveX installerservice that can be used with group policy templates and a safelist ofaccepted locations from where users can obtain and install safe ActiveXcontrols. More information can be found here: http://blogs.msdn.com/uac/archive/2006/06/14/631416.aspx