Wednesday, November 12, 2008

Activex Q And A

What's In This Document?

This document describes the changes in Internet Explorer 7 that reduce the number of ActiveX controls enabled by default

through a feature called "ActiveX Opt3In".

This document also describes some of the best practices for developing ActiveX controls intended to run in Internet Explorer.

These best practices have been compiled from the Security Development Lifecycle and from software developers who develop

and test ActiveX controls intended for safe use on the Internet.

Where does ActiveX Opt_In apply?

Where does it not apply?

ActiveX Opt3In applies to controls run in Internet Explorer and any applications which opt3in to Manage Add3ons through the

feature control key. ActiveX Opt3In can be enabled or disabled on a zone3by3zone basis through the IE Security Settings panel.

The setting, "Allow previously unused ActiveX controls to run without prompt" enables and disables the feature. By default,

ActiveX Opt3In applies to controls used on the Internet and restricted sites zones while controls used on an intranet and

trusted sites zones will not be affected by ActiveX Opt3In.

Should your control be on the pre_approved list?

Having your control on the pre3approved list can be valuable in some, but not all, situations. The situations below will help you

determine if you need your control to be on the pre3approved list.

Putting a control on the pre3approved list will attract the attention and scrutiny of the security research community. Any

vulnerabilities found in your control would expose a significantly larger number of users than if your control were not on the

pre3approved list. Keeping your control off the pre3approved list will keep users secure by default and protect customers who

are not using your control.

Your control should be on the pre3approved list if:

Your control is (or uses) an ActiveX control that is pre_installed on a user's machine by Windows or by an OEM.

Controls installed by Windows or by an OEM will be disabled by ActiveX Opt3In unless you take steps to pre3

approve them. Pre3approving your controls will insure that users have the best possible experience on your Web

site because it will work the way that you and the user expect.

Your control is intended to run from Internet Zone Web pages.

If, in the process of installing your application, ActiveX controls are installed which are intended to run on the

Internet, you might want to add these controls to the pre3approved list. Because the controls were installed by

software, and not by the user, the controls will be disabled by ActiveX Opt3In.

Your control should not be on the pre3approved list if:

Your control is not intended to be run in Web pages served from the Internet.

If your control is not intended to run in pages served from the Internet, then it should not be on the pre3approved

list. There are two steps we highly recommend in order to prevent the control from running in IE.

1. Killbitting the control [ ] will ensure that it can never load in

IE. Killbitting the control only requires setting a registry bit and is easily accomplished.

1. Killbitting the control [ ] will ensure that it can never load in

IE. Killbitting the control only requires setting a registry bit and is easily accomplished.

2. Do not mark the control safe for initialization or scripting. You should ensure this is true in both the

component categories as well as through IObjectSafety Mechanisms.

Your control is downloaded to the user's machine.

If your control is not locally installed on the user's machine then there is no need to be on the pre3approved list.

When the user downloads the control and chooses to install it, then the control will be approved. The user will not

be prompted again after choosing to install from the authenticode dialog. Note: only the control whose CLSID was

included in the object tag will be approved. If you have a single cab file which installs multiple controls, only the

control initialized in the object tag will be approved. You might need to pre3approve any other controls which

the .CAB file installs.

Your control is only intended to run on your corporate intranet or your control is for a line of business application.

You should not add these controls to the pre3approved list. ActiveX Opt3In is turned off by default in the intranet

zone so your corporate ActiveX controls will not be affected. It would be a good idea to zone3lock these controls or

restrict their capabilities when not running on an intranet.

If you have controls created for business applications which are not applicable to the general public, these

controls should not be pre3approved. You should work with the network administrators where your applications

run to ensure that the right controls get approved on your users’ machines. This can be done either through

Manage Add3Ons group policy [ ] or by adding the controls to the pre3

approved list in the registry.

How does my control get onto the pre_approved list?

Because pre3approved controls add to the attack surface of a user’s system, you should make sure that your controls have

been designed with security in mind. As the vendor for your ActiveX control, you are responsible for designing and testing it

to ensure that the control meets the best practices criteria described in this document. By adding your control to the pre3

approved list, you are warranting that you have reviewed the best practices for secure development outlined in this

document and certify that implementation of your control followed these or equivalent principles for secure development of

ActiveX controls. You are certifying that your control has no vulnerabilities to the best of your knowledge.

To put your control on the pre3approved list, you need to write the CLSID of the control to the following registry location.








If Microsoft determines that a control has a vulnerability and presents a danger to end users, Microsoft reserves the right to

remove that control at any time from the pre3approved list.

How to build secure ActiveX controls

Building a secure ActiveX control requires that designers, developers, and testers focus on security throughout the product

lifecycle. Designers must restrict the capabilities of the control so that it can accomplish only the work it needs to do without

any additional capabilities that might lead to exploits. Developers must code the control to act appropriately and safely when

handling data. Testers must include test cases based on potential threats to the control. At each stage in the development

lifecycle, security must be considered. The next sections go into more details on specific steps and considerations at each

stage in the lifecycle of a control.

Principles of Secure Design for ActiveX Controls

Designing for security is important because ActiveX controls are exposed to content from malicious Web sites. Any Web site

can try to use the control; all it needs is the control's class identifier (CLSID). When you designed your control, you may have

thought primarily about the control being used by some well intentioned pages, maybe even on your own website. To be safe

for running in the internet zone, you must design your control to be safe when loaded from any page on the internet,

particularly malicious pages. You need to ensure that malicious Web sites can't exploit your control to harm the user's system.

As you design, think about how the functionality of your control could be exploited and what measures you can take to

protect users from these exploits.

Restrict the capabilities of your control

Because an ActiveX control is a Microsoft Win32 component, there is no sandboxing33it can run without restrictions. You

should think about how you can restrict the functionality of your control to prevent others from repurposing it to malicious

ends. One of the first things you should think about when you consider writing an ActiveX control is if you really need an

ActiveX control to accomplish the functionality you need. If you do not need access to system resources, you can write the

control as a Dynamic HTML (DHTML) behavior [

behaviors/overview.asp ] .

In order for your control to be safe, the interface exposed to IDispatch (and therefore the Web) should be scoped as narrowly

as possible while still meeting your functional requirements. If your function does not absolutely require input parameters,

then remove them. If you can narrow the scope of the input parameters to a handful of known inputs, then do so. If your

control writes data to the local computer, or in any way changes the state or behavior of the system, take time to consider

how your control might be abused by a malicious third party.

Some scenarios you should consider when designing your control include the following.

Some scenarios you should consider when designing your control include the following.

How many and what kind of parameters does your control take?

Can you reduce the number of parameters or

more closely restrict the kind of data they accept?

Does the control rely on the URL of the hosting page to make security decisions? What happens if the control is

unable to obtain the hosting URL from Internet Explorer? Does it fail securely in this case?

Can the control be made to call other objects on the page, including Java applets? The Microsoft virtual machine

(Microsoft VM) called from native code in the control might attribute greater permissions to the control than script

on the page has. If the script can manipulate the control to call the Microsoft VM for it, an indirect security attack

might be possible.

Can the control tunnel out of the frame in which it is hosted and access content in another frame? The data

accessed could potentially violate the privacy of the user. You might prevent this by restricting the control to run

only within a particular domain.

Many ActiveX controls are initialized with data from local or remote sites, and most ActiveX controls are scriptable, supporting

a set of methods, events, and properties. Both initialization of persisted data and use of the controls through scripting require

safeguards to ensure that security is not violated. If your control does not read persisted data, don't mark it as safe for


Site_Lock Your Control

One powerful way to restrict the capabilities of your control is to lock it to a specific domain. If your ActiveX control is

designed only for a specific 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. However, you should be aware that site3locking does not guarantee another site

cannot use your control. Cross3site scripting flaws and man3in3the3middle attacks could expose your control to other Web

sites. Site3locking should only be used as defense in depth; it cannot be your primary line of defense.

A site3locking template that uses Microsoft Active Template Library (ATL) is available: SiteLock 1.14 Template for ActiveX

Controls [

ec9ea7fefbcb&displaylang=en ] .

Zone Lock your Control

If site3locking your control is too restrictive, you might still be able to zone3 lock your control. You could zone3lock your control

so it will only work when IE is in a specific zone, Internet, intranet, trusted sites, or restricted sites. As with site3locking,

however, zone3locking should be used as defense3in3depth and not a primary line of defense.

The SiteLock 1.14 Template also provides zone3locking functionality.

Ensure that ActiveX runs under least_privilege environments

By default, Windows XP user accounts were administrator accounts because many features and programs did not run

correctly under non3admin privileges. In Windows Vista, this will no longer be true. Users, by default, will not be

administrators on their machines. ActiveX controls must be able to operate fully in a non3admin environment. Furthermore,

when Protected Mode is enabled in IE the entire process will be running at a low integrity level, level 1. Controls need to be

tested under normal user account privileges and if possible even developed in these accounts.

More information on user account privileges can be found in Security in Longhorn: Focus on Least Privilege [ http:// ] and Understanding and Working in

Protected Mode Internet Explorer [


frame=true ] .

Secure Development Practices

Once you have designed and threat3modeled your control it is time to start implementing.

Prevent Denial of Service Attacks

Be sure the control doesn't loop infinitely or stop responding when given bad data or arguments. An attacker might tie up a

user's computer using your ActiveX control.

Safely Handle Memory

It is important for a secure ActiveX control to check all inputs and guard against buffer overruns. For example, if a control

receives an input string into a fixed3length buffer without checking its length first, it is possible for a malicious caller to

provide a string that is longer than the allocated buffer, overwriting other information in an unintended way. In some cases

these bugs can be exploited to make the control perform unsafe operations it was not designed to do. As the author of an

ActiveX control, you need to be vigilant. Never assume that a certain input conforms to certain requirements. Always check

the data to avoid these attacks. All inputs should have maximum sizes, and controls should be tested to perform safely, even

with inputs that are beyond specifications. See Fix Those Buffer Overruns [

dncode/html/secure05202002.asp ] for more information.

Limit Drag_and_Drop Capabilities

Drag3and3drop capabilities can be used to create many engaging and interactive experiences for users, however, ActiveX

controls need to enable and react to these capabilities in a responsible manner. If your control acts as a drop target then you

should not perform any unsafe action without prompting the user. If your control is a drag source, then you should be sure to

set the CFSTR_UNTRUSTEDDRAGDROP Clipboard format. This will insure that any program reading the dropped data will know

that it should not be fully trusted. You should also be aware that drag3and3drop capabilities in IE are now limited by a security

setting which may restrict the drag3and3drop capabilities of your control (URLACTION_SHELL_ENHANCED_DRAGDROP_


For more information on tagging clipboard data, please see Shell Clipboard Formats [


clipboard.asp ] .

For more information on the IE security setting regarding drag3and3drop, please see URL Action Flags [ http:// ] .

Safe for Scripting and Safe for Initialization

There are a few different mechanisms that IE uses to determine that controls are safe to initialize and script. The

IObjectSafety interface and Component categories manager are two tools that IE uses.

One of the first things to note about marking a control safe for scripting or initialization is that this should only be done for

controls which you actually intend to be initialized or scripted. If your control does not need scripting functionality then do

not mark it as such.

IObjectSafety [

iobjectsafety.asp ] is an interface that IE can use after a control is loaded to query the control and determine if the control

believes that it is safe to be initialized and scripted. The component categories manager is a method for controls to register

themselves as safe for use in IE. These are registry settings which IE can check prior to loading a control.

believes that it is safe to be initialized and scripted. The component categories manager is a method for controls to register

themselves as safe for use in IE. These are registry settings which IE can check prior to loading a control.

The IObjectSafety interface supports two methods, IObjectSafety::GetInterfaceSafetyOptions and

IObjectSafety::SetInterfaceSafetyOptions. The GetInterfaceSafetyOptions method should return the control's security

capabilities, safe for initialization and/or safe for scripting. The SetInterfaceSafetyOptions method is a request from the

container, IE, to the control and indicates that the control should configure itself to be safe for initialization or scripting.

The component category manager is a way that IE uses the registry to determine when controls are safe for initialization and

scripting. You should be sure to register your control with the component category manager when it is installing. Details on

how to set these registry keys can be found at How to mark MFC ActiveX controls as Safe for Scripting and Initialization

[ ] .

For more information on marking ActiveX controls safe for initialization and scripting via IObjectSafety and Component

Categories, please see Safe Initialization and Scripting for ActiveX Controls [

url=/workshop/components/activex/safety.asp ] .

Controls that Operate in the Local Machine Zone

ActiveX controls operating within the Local Machine Zone should not allow arbitrary content from the Internet to be written to

files in predictable locations without user interaction. Furthermore, controls operating in the Local Machine Zone should not

allow execution of arbitrary code directly or indirectly.

Design your control to be compatible with the Data Execution Prevention Feature

Data Execution Prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to

help prevent malicious code from running on a system. DEP is available on Microsoft Windows 2003 Server SP1, Windows XP

Service Pack 2, Windows XP Tablet PC Edition 2005, and on Windows Vista.

DEP works by preventing code execution from data memory that is not marked EXECUTABLE, such as the stack and heaps.

Hardware3enforced DEP detects code that is running from these locations and raises an exception when execution occurs.

Software3enforced DEP is a subset of hardware3enforced DEP, for machines that do not have supporting processors, and can

help prevent malicious code from taking advantage of exception3handling mechanisms in Windows.

Controls which are DEP compatible cannot execute code from any page which is marked non3executable. Note, ATL 7.1 and

earlier is not DEP compatible so if you use ATL, you will need to compile your control with ATL 8.0 or later.

IE provides a setting you can enable to test your control with the DEP feature. Go to the Tools | Internet Options | Advanced

tab and check the setting "Enable memory protection to help mitigate online attacks". (Note if you are running on Windows

Vista, this setting can only be changed if Protected Mode is disabled. Once the feature is enabled, you can run in Protected

mode.) You should use this IE setting to test your control and make sure it is compatible with DEP. Once your code is

compatible with DEP, you should link your code with /NXCOMPAT.

For more information, please see Changes to Functionality in Microsoft Windows XP Service Pack 2, Part 3: Memory Protection

Techniques [ ] and A Detailed Description

of the Data Execution Prevention (DEP) Feature [ ] .

Use Automated Tools to Evaluate Your Code

Use Automated Tools to Evaluate Your Code

Code reviews and quality assurance testing are highly valuable processes which are able to find and correct many bugs and

threats; however, more recently, new automated tools have become available which can review your code and flag potential

problem areas. One tool which Microsoft releases is called PreFast. It is available as part of Visual Studio Team System 2005

and also in the Windows DDK. PreFast will step through all the execution paths in your source code and look for errors in the

following areas.

Memory: Potential memory leaks, de3referenced NULL pointers, access to uninitialized memory, excessive use of

the kernel3mode stack, and improper use of pool tags.

Resources: Failure to release resources such as locks, resources that should be held when calling some functions,

and resources that should not be held when calling other functions.

Function usage: Potentially incorrect usage of certain functions, function arguments that appear incorrect,

possible argument type mismatches for functions that do not strictly check types, possible use of certain obsolete

functions, and function calls at a potentially incorrect IRQL.

Floating point state: Failure to protect floating point hardware state in a driver and attempting to restore floating

point state after saving it at a different IRQL.

Precedence rules: Code that might not behave as the programmer intended because of the precedence rules of C.

Kernel_mode coding practices: Coding practices that can cause errors, such as modifying an opaque memory

descriptor list (MDL) structure, failing to examine the value of a variable set by a called function, and using C/C++

string manipulation functions rather than the safe string functions defined in Ntstrsafe.h.

Driver_specific coding practices: Specific operations that are often a source of errors in kernel3mode drivers, such

as copying a whole I/O request packet (IRP) without modifying members and saving a pointer to a string or

structure argument instead of copying an argument in a DriverEntry routine.

This kind of automated code checking can greatly increase the security of your code and also reduce the number of bugs

found later during testing.

For more information on PreFast, please see PREfast Step3by3Step [

steps.mspx ] .

Digitally Sign your Control

A digital signature on your control enables users to verify the control's publisher and ensures that it has not been tampered

with since being published. Digital signatures help users make better trust decisions when determining if they should install a

control and help identify your control in the Internet Explorer's Add3on Manager.

Digitally signing controls is a vital step if you want users to be able to easily install your control. Users are strongly

discouraged from installing unsigned controls, and unsigned controls are blocked from installation by default.

Internet Explorer's Manage Add3Ons dialog displays information about all of the controls on a user's system. (To open the

dialog, choose Manage Add3 Ons from the Tools menu.) Signing your control will ensure that the Publisher field displays

correctly in this list. As you can see in the image below, some of the publishers appear as "(Not Verified)"—these are controls

which have not been signed.

If your control is installed by a CAB file or another executable, you must be sure to sign both the installation file (to enable

installation) and the .dll or ocx file containing the ActiveX control (to ensure your publisher name shows up without the "Not

verified" notice).

The name displayed in the Name Field of the Manage Add3Ons dialog is taken from the following registry setting.



{Control CLSID}


(Default)=(REG_SZ)"Control Name"

LocalizedStringPolicy=(REG_SZ) Localized Control Name

If you have a name that localized for other languages, set LocalizedString to point to the resource ID in your control's binary

file that contains the translated name. Manage Add3ons checks this value first, and uses it if it exists. If the localized string

does not exist, we fall back to the default value, which is (usually) the English name that does not get localized.

For more information, please see the following resources.

Signing and Checking Code with Authenticode [

security/authcode/signing.asp ]

Introduction to Code Signing [

intro_authenticode.asp ]

How to Judge control Security

The security of a control is ultimately a subjective judgment. The following questions are designed to help you think about the

security of your control. You can use them as part of your larger security review.

Can you limit domain usage or zone usage? See the section on site3locking your control for more information.

Are you exposing the user's private information over the network or to other users?

Can you read, write, create, detect or delete arbitrary persisted data either on the file system, the registry, a

buddy list, or a camera or other USB devices?

Does this control enable data to passing from one Internet site to another? From the intranet to the Internet?

From the local computer to the Internet?

Can this control host mobile code or script? If so, where does the code or script come from?

Does the control cause arbitrary operations or programs to execute on behalf of the user without notice?

Does this control circumvent/defeat a specific security feature in the browser, operating system, or another


Can a Web page use this control to cause the system to become unstable or stop responding?

Can this control be used to spy on the user without their knowledge?

Can this control be used to spy on the user without their knowledge?

Is there a possibility for cross3site scripting attacks using this control?

Does this control load its own data format? Does this data type have its own security implementation? Does this

data type allow macros?

Is history, statistical, or debugging information persisted on the local computer? Can a privacy conscious user

clear this information? Is the information ever sent over the network? Are globally unique identifiers (GUIDs) used

to track users?

These are some other general questions that you should consider as you design your control.

Are strings from the network validated, parsed, or filtered? What happens with the strings? What would happen if

they contain script? What happens to the strings after they are passed on to another component?

Where might there be buffer overruns? Have you done full testing for buffer overruns on all methods, properties,

and events?

What are you doing to stop an extraneous Web site from invoking the control?

If you don't mark the control "safe for scripting" or "safe for initialization", does that disable the purpose of the

control? Controls are marked as not safe for scripting or data initialization by default. Don't implement them unless

the functionality of the control is hampered without them.

Does the control present information to the user such that they can always identify its authenticity? Do you

digitally sign the control?

In addition, it is a good idea to document the following information about your control for reference.






DLL/OCX name and version

Secure Testing Practices

Validate the control for security using the following four practices.

Create Test Cases based on Threats Identified in the Threat Model

For each threat identified in your threat models, you should create a test case. The test cases should confirm that the

identified threat has been mitigated by the design or implementation of your control. While design and developer

documentation can describe how a control should behave, only testing can confirm how a control actually does behave.

Penetration Testing

Penetration testing is security testing in which testers aim to circumvent the security features of an application, or in this

case, an ActiveX control. Penetration testing includes, but is not limited to, denial of service, stress testing of all network

interfaces and fuzz testing of all file formats used by the control. Penetration testing should verify any explicit access controls,

such as ACLS and also verify correctness in all code which processes untrusted data. You should also test any security

mitigation you may have included in the control. For example, if you site3locked your control, you should do testing of the

control on other Web sites to insure that site3locking was properly implemented.

Fuzz Testing

Fuzz testing should be performed on any ActiveX control that handles data. The idea behind fuzz testing is to provide

structured but invalid inputs to your control. This kind of testing requires a high volume of test cases, with many variations

and mutations in the data that you test the control with. Most often, fuzz testing is done using automated tools. The objective

of fuzz testing is not to ensure that your control acts in an expected manner on the invalid data but to ensure that your

control acts in a safe manner when given invalid data. Your control should not crash or cause a buffer overrun when handling

invalid data.

Fuzz Testing should be done on the following areas of your control.

Any methods within the control

All parameters used by the control

Any data from a remote source, for example if you have a property that takes a URL you should fuzz test the URL

itself but you should also fuzz test the file that is downloaded from the URL.

There are two different parameters to consider when choosing the fuzz data you test your control on. The first consideration

you might make is whether to use a smart or dumb form of data generation. The differences in these two forms are similar to

the difference between black box and white box testing. Dumb data generation, similar to black box testing, generates input

without knowledge of the intended data format or processing functions. Smart data generation, similar to white box testing,

generates input based on knowledge of the correct data structure and how it is processed in the control. A second

consideration when generating data is whether to generate new data or to mutate valid data. Generating new invalid data

may be more appropriate when you are doing dumb fuzz testing. Mutating valid data so that it becomes invalid may be more

appropriate when you are doing smart fuzz testing. For most controls you will want to use a combination of dumb and smart

fuzz testing and generate some of the test data while also mutating other data.

Regression Testing

Regression Testing

Regression testing ensures that new changes in the code have not broken any functionality which was previously working.

Regression testing needs to be done at every major milestone in the development cycle. It is important to regression test not

only on the functionality of your controls but your security test cases as well.


We would like to thank the following for their help in preparing and reviewing this article: David Ross, Philip Nachreiner, Eric

Lawrence, Mike Friedman, Patrick Mann, Levent Besik, Cullen Sauls, Josh Cain, and Madhuvan Gupta.

Sharon Cohen and Rob Franco are program managers on the Internet Explorer team.

No comments:

Your Title