Recently, I wrote an article called Web security features of Internet Explorer 8. In that article, I explained that although better security was one of Microsoft's stated goals, it was a secondary goal and that Internet Explorer 8 was designed primarily to improve Web-based standards.
Internet Explorer (IE) security's biggest enemy is the browser-based exploit, and Microsoft worked hard in versions 6 and 7 to make Internet Explorer less vulnerable to exploits related to malicious code built into Web pages. But there is still a lot of work to be done.
The role of ActiveX in browser exploits
Often, these types of exploits are delivered through ActiveX controls, software modules that are based on Microsoft's Component Object Model (COM) architecture. ActiveX controls are kind of like miniature applications that can act as browser plug-ins. Essentially, they allow a website to interact directly with Windows and to perform functions that would be impossible using standard HTML code or scripting techniques.
Unfortunately, completely blocking ActiveX controls isn't really an option. There are a lot of perfectly legitimate websites that depend on them. In fact, Microsoft itself makes extensive use of ActiveX controls. Often when you download a patch or utility for Windows Vista, the website containing the download performs a check to make sure you are running a properly licensed version of Vista. This license check uses ActiveX controls.
Because so many ActiveX controls turn out to be malicious, Microsoft designed Internet Explorer 7 so that it displays a warning every time a site attempts to use an ActiveX control. The problem is that the casual user does not typically understand what an ActiveX control is, or what the consequences of allowing an ActiveX control to run might be. Therefore, Internet Explorer 7 tends to be prone to the same types of exploits as previous versions because the end user is allowing malicious code to run.
IE8 can help manage the threat of ActiveX
Internet Explorer 8's design helps reduce the chances of a malicious ActiveX control wreaking havoc on a system. There are two different mechanisms in place that help accomplish this goal.
The first is called Per-Site ActiveX. The idea behind this mechanism is that some sites require ActiveX controls and others do not.
For example, suppose you visit Microsoft's website, and the page requires you to download a specific ActiveX control in order to accomplish whatever it is that you're trying to do. You download ActiveX. Because the control came from a legitimate source, you probably don't think it's malicious. However, there could be ways in which someone with malicious intent could use an otherwise benign ActiveX control to his or her advantage. In fact, there have been numerous documented cases of malicious websites checking for the presence of certain non-malicious ActiveX controls and then using those controls in ways they were not originally intended.
The Per-Site ActiveX control feature reduces the chances of this happening because, by default, ActiveX controls are only allowed to run if they are called by the site that originally installed them. Furthermore, administrators are allowed to control where an ActiveX control is allowed to run, and the controls can now be installed so that they are only valid for the user to install them, and not for every user on the system.
Data Execution Prevention in IE8
One more security feature that I want to quickly mention is Data Execution Prevention. Data Execution Prevention is a security feature built into the 64-bit version of Windows Vista. It prevents certain types of code from writing data to executable memory space. Internet Explorer 8 is going to be designed to make use of the security feature. If a website attempts to write to executable memory space, then the browser window will automatically be closed and the process will be terminated.
About the author: Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox.
This was first published in July 2008