NewsBot
1
Hi, I’m Matt Crowley, Program Manager for Extensibility with Internet Explorer. The team was very excited to be at the RSA security conference last month discussing the security features of Internet Explorer 8 Beta 1. In this, the second part of the IE8 Security blog series, I describe the ActiveX improvements in IE8 and summarize the existing ActiveX-related security features carried over from earlier browser versions.
Per-User (Non-Admin) ActiveX
Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges. This improvement makes it easier for an organization to realize the full benefit of User Account Control by enabling standard users to install ActiveX controls used in their day-to-day browsing.
If a user happens to install a malicious ActiveX control, the overall system will be unaffected, as the control was installed only under the user’s account. Since installations can be restricted to a user profile, the risk and cost of compromise (and, in turn, the total cost of administering users on a machine) will be lowered significantly.
Per-User ActiveX was designed with compatibility in mind—most existing ActiveX controls will not have to be rewritten to benefit from this feature; the only change will be repackaging. As in Internet Explorer 7, when a webpage attempts to install a control, an Information Bar is displayed to the user.
By clicking on the information bar, users can choose to either install the control machine-wide, or install it only for their own user account. The options in this menu will vary depending on the packaging of the control and the rights of the user.
The available options depend on Group Policy settings for per-user ActiveX installations and whether or not the control has been packaged to allow per-user installation.
While this feature offers the possibility of lowering total cost of ownership, IT Administrators running managed environments may elect to disable this feature via Group Policy. For more information regarding Per-User ActiveX, please refer to the Non-Admin ActiveX Controls article in MSDN’s IE8 Beta 1 Whitepapers.
ActiveX Opt-In
Recognizing that any binary extensibility mechanism increases attack surface, ActiveX Opt-In was introduced with Internet Explorer 7.
By default, ActiveX Opt-In disables most controls on a user's machine. When the user encounters a Web page with a disabled ActiveX control, they will see an Information bar with the following text: "This website wants to run the following add-on "ABC Control" from "XYZ Publisher". If you trust the website and the add-on and want to allow it to run, click here …" The user can then choose to enable the ActiveX control from this Information bar.
ActiveX Opt-In allows some controls to run by default:
Per-Site ActiveX
When a user navigates to a Web site containing an ActiveX control, IE8 performs a number of checks, including a determination of where a control is permitted to run. This check is referred to as Per-Site ActiveX, a defense mechanism to help prevent malicious repurposing of controls. If a control is installed, but is not permitted to run on a specific website, an Information Bar appears asking the user whether or not the control should be permitted to run on the current website.
Users can use the Information bar to allow the control for a specific Web site or allow the control for all Web sites.
IT Professionals administering a system of computers running Internet Explorer 8 may choose to preset allowed controls and their associated domains. Such settings can be configured using Group Policy.
For more information regarding Per-Site ActiveX, please refer to the Per-Site ActiveX article in MSDN’s IE8 Beta 1 Whitepapers.
Enforcing Per-Site with ATL SiteLock Technology
If your ActiveX control is designed for use only on your web site, then locking it to the domain of that Web site will make it harder for other sites to repurpose the control in a malicious manner. See Developing Safer ActiveX Controls Using the Sitelock Template for more information.
Reducing Exploit Risk with DEP/NX, “Killbits,” and Servicing
Working with your processor and Windows, IE8 helps reduce the exploitation of vulnerable controls through Data Execution Prevention. See the previous post in this series, IE8 Security Part I: DEP/NX Memory Protection, for more information on how to ensure that your ActiveX controls are DEP/NX compatible, as well as information on how to opt-in to other available protections.
If a vulnerable control has been exploited, IE has included a poison-pill option—the “killbit”— to block usage of specific controls within the browser. Vendors who are aware of a vulnerability in their control should contact Microsoft to setup a killbit for a future software update package. For more information, please refer to Knowledge Base article 240797, How to stop an ActiveX control from running in Internet Explorer.
As with standard desktop software, it is important to keep controls up-to-date to ensure compatibility with newer systems and lower the risk of compromise through evolving security threats. For more information on updating ActiveX controls, please refer to the IE Blog entry Good Practices for ActiveX Updates.
Working with Users through Manage Add-Ons
While most end users aren’t aware of the inner-workings of ActiveX controls or their enterprise policy on them (if applicable), users are able to find out information about the controls installed for use in Internet Explorer through Manage Add-Ons. It is important for developers to ensure that their controls are not only performant and secure, but also open in the information they provide.
Controls are identified by Name, Publisher, Version, and Class ID within the Manage Add-Ons interface. Given this, control developers are encouraged to include this metadata in release builds of their controls.
For more information on making sure that your ActiveX control properly conveys information about itself to users, please refer to Christopher Vaughan’s post Add-on Management Improvements in Internet Explorer 8 as well as the MSDN Article Best Practices for ActiveX.
Thanks for your help in ensuring your ActiveX controls are secure!
Matthew David Crowley
Program Manager
Internet Explorer Extensibility
More...
View All Our Microsoft Related Feeds
Per-User (Non-Admin) ActiveX
Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges. This improvement makes it easier for an organization to realize the full benefit of User Account Control by enabling standard users to install ActiveX controls used in their day-to-day browsing.
If a user happens to install a malicious ActiveX control, the overall system will be unaffected, as the control was installed only under the user’s account. Since installations can be restricted to a user profile, the risk and cost of compromise (and, in turn, the total cost of administering users on a machine) will be lowered significantly.
Per-User ActiveX was designed with compatibility in mind—most existing ActiveX controls will not have to be rewritten to benefit from this feature; the only change will be repackaging. As in Internet Explorer 7, when a webpage attempts to install a control, an Information Bar is displayed to the user.
By clicking on the information bar, users can choose to either install the control machine-wide, or install it only for their own user account. The options in this menu will vary depending on the packaging of the control and the rights of the user.
The available options depend on Group Policy settings for per-user ActiveX installations and whether or not the control has been packaged to allow per-user installation.
While this feature offers the possibility of lowering total cost of ownership, IT Administrators running managed environments may elect to disable this feature via Group Policy. For more information regarding Per-User ActiveX, please refer to the Non-Admin ActiveX Controls article in MSDN’s IE8 Beta 1 Whitepapers.
ActiveX Opt-In
Recognizing that any binary extensibility mechanism increases attack surface, ActiveX Opt-In was introduced with Internet Explorer 7.
By default, ActiveX Opt-In disables most controls on a user's machine. When the user encounters a Web page with a disabled ActiveX control, they will see an Information bar with the following text: "This website wants to run the following add-on "ABC Control" from "XYZ Publisher". If you trust the website and the add-on and want to allow it to run, click here …" The user can then choose to enable the ActiveX control from this Information bar.
ActiveX Opt-In allows some controls to run by default:
- A small list of common controls intended for use in the browser.
- Controls which were used in IE on a user’s machine before upgrading to IE8.
- Controls which are installed through IE.
Per-Site ActiveX
When a user navigates to a Web site containing an ActiveX control, IE8 performs a number of checks, including a determination of where a control is permitted to run. This check is referred to as Per-Site ActiveX, a defense mechanism to help prevent malicious repurposing of controls. If a control is installed, but is not permitted to run on a specific website, an Information Bar appears asking the user whether or not the control should be permitted to run on the current website.
Users can use the Information bar to allow the control for a specific Web site or allow the control for all Web sites.
IT Professionals administering a system of computers running Internet Explorer 8 may choose to preset allowed controls and their associated domains. Such settings can be configured using Group Policy.
For more information regarding Per-Site ActiveX, please refer to the Per-Site ActiveX article in MSDN’s IE8 Beta 1 Whitepapers.
Enforcing Per-Site with ATL SiteLock Technology
If your ActiveX control is designed for use only on your web site, then locking it to the domain of that Web site will make it harder for other sites to repurpose the control in a malicious manner. See Developing Safer ActiveX Controls Using the Sitelock Template for more information.
Reducing Exploit Risk with DEP/NX, “Killbits,” and Servicing
Working with your processor and Windows, IE8 helps reduce the exploitation of vulnerable controls through Data Execution Prevention. See the previous post in this series, IE8 Security Part I: DEP/NX Memory Protection, for more information on how to ensure that your ActiveX controls are DEP/NX compatible, as well as information on how to opt-in to other available protections.
If a vulnerable control has been exploited, IE has included a poison-pill option—the “killbit”— to block usage of specific controls within the browser. Vendors who are aware of a vulnerability in their control should contact Microsoft to setup a killbit for a future software update package. For more information, please refer to Knowledge Base article 240797, How to stop an ActiveX control from running in Internet Explorer.
As with standard desktop software, it is important to keep controls up-to-date to ensure compatibility with newer systems and lower the risk of compromise through evolving security threats. For more information on updating ActiveX controls, please refer to the IE Blog entry Good Practices for ActiveX Updates.
Working with Users through Manage Add-Ons
While most end users aren’t aware of the inner-workings of ActiveX controls or their enterprise policy on them (if applicable), users are able to find out information about the controls installed for use in Internet Explorer through Manage Add-Ons. It is important for developers to ensure that their controls are not only performant and secure, but also open in the information they provide.
Controls are identified by Name, Publisher, Version, and Class ID within the Manage Add-Ons interface. Given this, control developers are encouraged to include this metadata in release builds of their controls.
For more information on making sure that your ActiveX control properly conveys information about itself to users, please refer to Christopher Vaughan’s post Add-on Management Improvements in Internet Explorer 8 as well as the MSDN Article Best Practices for ActiveX.
Thanks for your help in ensuring your ActiveX controls are secure!
Matthew David Crowley
Program Manager
Internet Explorer Extensibility
More...
View All Our Microsoft Related Feeds
