Managing Mobile Code with Microsoft Technologies

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Published: August 31, 2000

By Sean Finnegan, Microsoft Corporation

On This Page

What Is Mobile Code?
What Is The Risk?
Tools To Protect Yourself
Putting It All Together


The widespread adoption of the global Internet has allowed people to access information from around the world. Oftentimes the information is not pure data but also takes the form of programs designed to provide services. These programs can take a variety of forms including scripts within documents and e-mail, or code objects running within web pages - these dynamic programs that can move across the Internet are often referred to as "mobile code". However, with this broad access to information and services has also come an increased risk that a malicious person will use these services to attack unwary users.

The purpose of this paper is to describe the types of "mobile code" associated with Microsoft products, the risks they could pose, and the tools and technologies that Microsoft provides to protect you from these risks. While the focus of this paper is exclusively on Microsoft products, these same types of mobile code exist in products from many vendors. However, the popularity of the Microsoft technologies has made them a favorite choice for attackers wishing to reach a large audience.

What Is Mobile Code?

The term "mobile code" typically refers to interpreted or executable content that can be downloaded and run on a user's workstation. These mechanisms are often used to provide rich and dynamic content to users visiting web sites or to automate common tasks. Like any tool though, these same mechanisms can be used for malicious purposes as well. The use of mobile code is no longer restricted to web browsers either; as HTML has become the most ubiquitous format for displaying data, many applications have started supporting HTML documents as well. The most common example of this is email. Most commercial email clients now support the rendering of messages in HTML. Without additional safeguards, these mail messages can include any of the forms of mobile code and be conveniently pushed directly to the target user. The following section describes the most common forms of mobile code.

Embedded Script (JScript /VBScript)

Internet Explorer includes a built-in interpreter to parse Jscript or Visual Basic scripts (VBScript) embedded within web pages. These scripting engines provide the "glue" to manipulate other objects on the web page. Both scripting engines offer common programming constructs to control program flow (e.g. If, Then, Else, For, Do, etc), perform simple mathematical functions, evaluate conditions, and manipulate data types. In addition, these languages offer the ability to load objects, such as ActiveX controls and Java applets, call methods on them, or set and get their properties. On the Microsoft Windows family of operating systems both scripting engines also include at least one "built-in" object, the FileSystemObject, which can be called to manipulate files or directories on the local file system as long as those scripts aren't being run from a web page. More information on these objects is provided below.

In addition to Internet Explorer, the Windows Script Host (WSH) also provides the ability to run VBScript and JScript directly on Windows platforms. This scripting engine is extensible to add support for new languages, such as REXX and Perl, and can be used to automate tasks. These scripts are run in the user's security context just like any other program on the local workstation and are not subject to the same restrictions placed on code run within the browser. Once downloaded and run, the script can perform any action the user is permitted such as manipulating the registry and file system through existing objects or invoking other installed applications through COM interfaces.

ActiveX Controls

The Component Object Model (COM) is Microsoft's architecture for creating programming objects that can be reused and provide services to other programs. Most of Microsoft's productivity applications are composed of many COM objects, such as Microsoft Word, Excel, PowerPoint presentation graphics program, and Visio drawing and diagramming software. An ActiveX control is simply a COM object that is designed to be downloaded and used within web pages. Once an ActiveX control is installed on the system it runs directly on the workstation in the security context of the web browser (normally the logged on user). These objects can be scripted to perform operations by calling their properties and methods from embedded script within the web page. An ActiveX control can perform any operation the user can. This makes ActiveX controls tremendously powerful for developing browser-based applications, but also makes them very dangerous if normal safeguards are not employed. When developing ActiveX controls, the developer must implement sufficient security measures to prevent their malicious use. If the control is not safe for use by any web page, its use from within Internet Explorer can be disabled or the tools described below can be used to allow the control to run only when appropriate.

Java Applets

Like ActiveX controls, Java applets are reusable code modules that can be downloaded and installed on the client machine. They are created using the Java programming language and compiled into platform-neutral byte-code. Once downloaded to the client machine the applet is loaded into a Java Virtual Machine (VM) that interprets the byte-codes and runs the applet. The VM normally restricts what the applet can do, thereby limiting the functionality of the applet, but also limiting the amount of damage a potential attacker could do.

"Built-In" Objects

Internet Explorer also includes several objects that are used to perform advanced scripting functions. These objects are accessible from VBScript or JScript and include the control that implements IE's Dynamic HTML support and the FileSystemObject used to access the local file system. These objects implement their own safeguards and, when invoked by Internet Explorer, the browser provides information to these controls that can be used to make security decisions. For instance, the FileSystemObject will only allow access to the file system if a web page is in the Local Machine Security Zone (more on this later) or if it is called directly from the Windows Script Host. Failures in the security of an object (either built-in or downloaded) have been perceived as script security issues.

Visual Basic for Applications (VBA)

Many Microsoft and third-party applications include support for VBA to allow scripting of the application (via macros) and to allow the application to be manipulated within other applications. VBA is another form of VBScript and offers that same type of services (programming constructs and object manipulation). The VBA scripts are typically embedded within application documents, such as Microsoft Word documents, and can be triggered to activate in response to certain application actions such as opening the document or clicking on a spreadsheet cell. Like scripts run from the Windows Script Host, these scripts are executed locally on the workstation in the security context of the logged on user, and are not subject to the same restrictions as script run within the browser.

E-Mail Attachments and Downloaded Executables

While not truly a form of mobile code, executable programs that are received in e-mail or downloaded from the Internet also bear mention. If run, these programs do so in the user's security context and therefore are only limited by the restrictions placed on that user account. Once a user downloads or detaches a program or script, the operating system has no way of knowing whether it should be trusted or not.

What Is The Risk?

So how can mobile code be used to attack systems? How much damage can mobile code inflict? Below we will discuss several types of potential attacks and their likelihood of success.

Browser attacks

The class of attack that typically causes the most concern is attacks that can occur simply by the user visiting a malicious web site. Organizations that force users to go through an application layer proxy can screen for potentially malicious content. However, these proxy server scanners can be defeated by establishing an SSL/TLS session to encrypt the traffic from the client to the malicious web site.

Since its inception, a great deal of concern has centered on the threat posed by an intentionally malicious ActiveX control. ActiveX controls are native code and therefore a malicious control can be programmed to do anything on the user's workstation. However, uniformly restricting the capabilities of ActiveX controls would limit their usefulness in developing rich browser based applications. To provide a combination of flexibility and security, Microsoft instead implemented as a part of the original design of ActiveX a way to allow controls from trusted authors to have full access to the machines while preventing untrusted software from being installed.

The model used to protect against rogue ActiveX controls was based on the same principles used when shopping for software at a local retailer. The average home user is free to go to a software store, purchase, and install any application they wish. By doing so they have made a trust decision about the publisher of that software. They have decided that the producer of the software is trustworthy and produces a quality product that they don't believe will take any malicious actions against them. Should some undesired effect occur, they also know whom to contact from the information on the product packaging. By including Authenticode technology with ActiveX Microsoft brought this same trust model to code download.

Like ActiveX controls, Java applets are also downloaded from web sites and run within the browser. However, Java applets are downloaded from web sites as platform neutral byte-codes and are run within a Virtual Machine (VM) on the user's workstation. VM-enforced security restricts the actions the applet can take and is therefore often referred to a "sandbox". This model offers the advantage that an applet only runs with a subset of the user's privileges, but this increased security comes at the expense of performance and flexibility. Java applets can, however, be given permission to run with the user's full privileges by signing the applet with full permissions (described below).

While there is certainly the potential for malicious users to build intentionally malicious ActiveX controls or Java applets, in reality there are relatively few of them. Instead, most developers are creating objects to solve business problems or provide commercial services to customers. Recently however, hackers have looked to find ways to script useful controls that are already installed or permitted to perform potentially malicious actions.

Many ActiveX controls and Java applets (hereafter referred to jointly as simply "objects") are designed so that web developers can pass in parameters or call specific methods of the object. An attacker may try to use VBScript or JScript to pass parameters into the object that the object author never intended. These parameters could allow the attacker to bypass security measures built into the object or perhaps overflow a memory buffer in the object either causing the browser to crash or running additional malicious code. This type of attack is known as a "buffer overrun".

To put the risk of a browser-based attack in perspective you must recognize that the user must first find a site that is intentionally designed to be malicious. This site must also maintain its presence, something particularly difficult if the site is hosted by a commercial ISP and is known to be malicious. Most ISPs will shut down sites they host that are engaging in hostile or illegal activity, and commercial sites would likely not engage in such actions since that would detract from their business. These two factors make such an attack highly unlikely to affect users that only visit established commercial web sites.

Mail client attacks

While a user must find and visit a malicious web page for an attck to be effective, these same types of attacks can be directed at large user populations using HTML based email. Microsoft Outlook messaging and collaboration client and Outlook Express both use Internet Explorer within the mail client to render HTML formatted mail messages. Inside these HTML messages can be VBScript or JScript just as with a web page. However, these HTML messages can only link to objects that exist on the user's workstation or exist on the network – they cannot include objects as a part of the message1 . If the user is reading mail offline then any links to remote objects or any messages that attempt to redirect the user to another site will fail.

The "ILOVEYOU" virus brought back to the forefront the dangers of attachments in email messages. An attacker can include any sort of program they wish to an email and send it out. If a user chooses to run it, the program will operate in the user's security context. The Microsoft Outlook attachment security patches described in this paper were designed to help users identify these potentially malicious attachments.

Other Attacks

In addition to HTML, other documents can contain script as well. As was discussed earlier, many applications include a scripting engine so that data manipulation can be automated or to allow the manipulation of one application from another – such as building a Microsoft Excel spreadsheet of the costs of a project based on a Microsoft Visio diagram. When these documents are downloaded and run locally, the scripts are capable of performing any action that the user can perform using the installed objects.

In addition to an embedded script, a user might also download and run a malicious program. Often a malicious program is disguised as something useful or entertaining to trick the user into running it. Programs such as this also may not give any indication to the victim of their true purpose. Instead, the program may secretly place a "Trojan Horse" on the system that allows an attacker later access to the machine. At the time this document was written, several emails were circulating on the Internet claiming to be software upgrades from Microsoft. In fact, these programs were Trojan horses. The best countermeasure against this threat is to run an up to date virus scanner and always question the source of downloaded programs. Of course, the most secure action is simply not to open attachments from unknown or unexpected sources. Microsoft and other commercial companies digitally sign programs they distribute so their authenticity can be verified and Microsoft never distributes programs via e-mail.

Finally, knowing the source of an e-mail is not always enough to guarantee the safety of the attachment. Malicious programs, such as the "I Love You" virus, use the programmability of mail packages to forward copies of themselves from the victim's mail account to their friends and associates. When in doubt about an attachment you receive from a colleague it is prudent to check with them prior to opening it.

Tools To Protect Yourself

The previous section discussed many of the risks associated with the use of mobile code. To address these risks Microsoft has included within our products a variety of tools to increase your security. These tools are designed to enable a user or corporate administrator to evaluate the risk from attack and deploy appropriate countermeasures without losing a rich user experience.

Internet Explorer Zones

Within the Internet Explorer browser there are many security settings that administrators or users can configure to properly manage the risk from mobile code. Despite having all of these options it is often impossible to define a single security policy that is applicable to all sites. Consider the corporate intranet where web sites may use rich content such as ActiveX controls, unrestricted Java applets, and extensive scripting for tasks such as entering payroll data or performing other employee self-service actions. At the other end of the spectrum are sites that you know to be of questionable intent, but which users may still need to visit to gather information – you want to permit this with adequate safety measures. The bottom line is that all web sites are not trusted equally and security policy must be flexible enough to address this fact.

To address this issue, Internet Explorer includes the ability to group web sites into Security Zones. Each zone can then have the appropriate security policy applied to it.

Internet Explorer 4.0 and higher ship pre-configured with four security zones and additional zones can be added programmatically using the Internet Explorer Zone Manager API. The four default zones are described as follows:

Local intranet zone: Sites are considered a part of this zone if they meet the following 3 sets of criteria, each of which may be individually disabled.

The site is considered on the local intranet and is not listed in any other zone. When a Microsoft Proxy server is used to separate your intranet from the Internet then the list of local intranet sites is downloaded to the browser from the proxy's Local Address Table (LAT).

The site is defined in the Internet Explorer proxy settings as an address that will bypass the proxy server for access.


The address being referenced is a UNC path (e.g. \\server\share\folder\file.htm) or the server name does not have a "." in it.

In addition to these criteria, sites can be added directly to the local intranet zone, either by host name, IP address, DNS domain, or IP subnet. In IE 5.0 or later these sites added directly to the zone can also be required to use SSL/TLS for server authentication in order to be considered in the local intranet zone.


The default security level for the Local Intranet zone is Medium.

Trusted Sites zone: This zone contains sites you trust—sites that you believe you can download or run files from without worrying about damage to your computer or data. You can assign sites to this zone by their name, IP address, DNS domain, or IP subnet just as with the local intranet zone. This zone can also require that a site use SSL/TLS for server authentication in order to be considered in the Trusted sites zone (IE 5.0 and later only). The default security level for the Trusted Sites zone is Low.

Restricted Sites zone: This zone contains sites you don't trust—that is, sites that you're not sure whether you can download or run files from without damage to your computer or data. You can assign sites to this zone using the same tools as with the local intranet and trusted sites zones, however, the option to require SSL/TLS is not available. The default security level for the Restricted Sites zone is High.

Internet zone: By default, this zone contains anything that is not on your computer or an intranet, or assigned to any other zone. The default security level for the Internet zone is Medium.

There is actually a fifth built-in zone called the My Computer zone (which contains files on your local computer) that is configurable only from the Microsoft Internet Explorer Administration Kit (IEAK); configuration settings for the My Computer zone are not available in the browser interface.

Each zone comes pre-configured with a different security level that should provide adequate security to most organizations when sites are categorized appropriately. Each of the 106 security settings within each zone can be customized to meet your organizational needs. Some of the security settings defined within each zone include:

  • Download signed ActiveX controls (Disable/Enable/Prompt)

  • Download unsigned ActiveX controls (Disable/Enable/Prompt)

  • Initialize and script ActiveX controls not marked as safe (Disable/Enable/Prompt)

  • Run ActiveX controls and plug-ins (Administrator approved/Disable/Enable/Prompt)

  • Allow cookies that are stored on your computer (Disable/Enable/Prompt)

  • Allow per-session cookies (Disable/Enable/Prompt)

  • Active scripting (Disable/Enable/Prompt)

  • Scripting of Java applets (Disable/Enable/Prompt)

  • A variety of Java VM security restrictions

It is easiest to customize these settings using the Internet Explorer Internet Options dialog. In addition, corporate administrators or ISPs can use the IEAK or Windows 2000 Group Policy to define the configuration centrally for their clients. The IEAK allows corporate administrators or ISPs to create a customized version of Internet Explorer that can then be distributed to their users on CDs or over the network. The customized version can come preset with any of the desired security settings discussed in this document.

If you do not have the ability to distribute these changes using the IEAK or GPO then it is possible to redistribue the following registry key that contains the zone security settings:

[HKEY_CURRENT_USER \Software \Microsoft \Windows 
\CurrentVersion \Internet Settings\Zones]

Under this registry key is a series of sub keys that each store the settings for a particular zone:

0 = My Computer zone

1 = Local intranet zone

2 = Trusted sites zone

3 = Internet zone

4 = Restricted sites zone

The definition of how sites are categorized into zones is stored beneath the registry key:

[HKEY_CURRENT_USER \Software \Microsoft \Windows 
\CurrentVersion \Internet Settings\ZoneMap]

It is recommended that you still set these keys using the user interface and then export the registry key(s) to a .REG file for installation on additional machines. Note that these settings are stored in the HKEY_CURRENT_USER hive of the registry and are therefore configurable on a per user basis. However, identical registry keys exist in the HKEY_LOCAL_MACHINE registry hive that will place the same restrictions on all users of a particular machine. Command line tools such as regedit (with a format of regedit /s foo.reg) can be used as a part of a logon script or distributed via SMS to configure the zone settings for a user. Further detail on the registry keys used by Internet Explorer Security Zones is available in Microsoft Knowledge Base article 182569.

For further information on how to programmatically configure the Internet Explorer zones, the effect of specific zone security settings, or how to create new zones, please consult the MSDN online library at the following URL.

Email Security Zones

Microsoft Outlook (98 and higher) and Outlook Express (4.0 and higher) can also take advantage of security zones. In the Outlook or Outlook Express security configuration you have the option of determining which zone security settings will be used when viewing HTML e-mail. Note that you can only choose from the Internet zone or the Restricted sites zone and that any modifications to the zone settings will affect Internet Explorer as well as Outlook and Outlook Express.


Microsoft Authenticode is the name used to describe a family of technologies for digitally signing and verifying executable content. A person developing an ActiveX control or Java applet can digitally sign the software cabinet (.CAB) file using the private key from a digital certificate obtained from a commercial Certificate Authority, such as Verisign, GTE or Thawte, or from a corporate Certificate Authority such as the Windows 2000 Certificate Services.

The Microsoft code signing tool signcode.exe is used to sign the program and will prompt the signer for a certificate stored in the Microsoft CryptoAPI. Certificates and their associated private keys are automatically stored in the Microsoft CryptoAPI if they are requested from a web page using Internet Explorer. If the certificate is obtained via some other means then it can be loaded into the CryptoAPI using the PKCS#12 (.p12 or .pfx file) format and the certificate import wizard.

The signcode.exe tool will only sign files if the certificate used asserts the value for Code Signing ( in the Enhanced Key Usage certificate extension. The code signing tool can be downloaded from in the Security \ Authenticode section.

Internet Explorer automatically validates the digital signature on the mobile code when the user downloads the CAB file. A valid signature tells the user who created the code as well as verifying that the code has not been altered since the author signed it. This allows the person downloading the code to make a trust decision about the author of the program – "do I believe that this person/company produces software that is free of viruses and would not attempt any malicious actions?" If you consider the traditional method of distributing software by walking into a computer store and purchasing it off the shelf, the Authenticode signature acts like the shrink-wrapped software box and "Certificate of Authenticity". The fact that the software is signed does not attest to the quality any more than the fact the software is in a shrink-wrapped box does.

Not all users want to make a trust decision every time they install a new piece of software and in a corporate environment it may be advisable to have some central authority establish rules that guide which software is installed. The Internet Explorer Administration Kit (IEAK) allows corporate administrators to customize the Authenticode policy settings and develop a custom browser configuration that can be deployed to users. This custom configuration could prevent the user from running any unsigned code or allow them to only run code signed by specific authors. For example, you might establish a process where all internally developed code has to be approved before deployment – this could be a part of your existing configuration management process. This process might even include a code review to ensure that the program can't be used for malicious actions. Once this program has been approved for deployment the configuration control body would digitally sign it. To enforce this process all browsers within the company would have their Authenticode settings configured to only run controls signed by this configuration control board's certificate.

Furthermore, these Authenticode settings can be locked down and centrally managed using the IEAK. For users running in Windows 2000 domains, the management capabilities of the IEAK are also available as Group Policy Objects that can be applied to domains or organizational units.

Since Java applets are run within a Virtual Machine (VM) in the browser, IE coupled with Authenticode technology can be used to define the level of trust required to run an applet. An author signing a Java applet can state in the signature which permissions the applet requires. For example, the applet might need to access the local hard disk or transmit data across the network. The user, or network administrator, can define which rights applets should be permitted and the Microsoft Java VM will check that the applet can run within the specified policy prior to loading it. Should a running applet attempt an action that it did not request in its Authenticode signature the VM will stop execution of the applet. The list of available permissions with which a Java applet can be signed is available at:


Most web pages that use ActiveX controls also provide the client with information on where to download and install the control. This information is provided using the CODEBASE keyword in the HTML tag and references the URL of the component itself or a CAB file containing the control and installation instructions (INF file). The following HTML code snippet is from the home page.

<OBJECT type="application/x-oleobject" classid="clsid:
Codebase=",2000,0326,2" width=100% height=34>

The <OBJECT> tag is used to load an ActiveX control within a web page. When Internet Explorer parses this HTML it will first check the registry to see if the object is already installed by searching for the classid listed in bold above. If the object is installed, then the registry entry will list the program file to run. If the classid cannot be found in the registry then by default IE will look for the Codebase keyword in the HTML tag. In the example above, Internet Explorer is given a hint by the web page author that the desired control can be found as on the web site

However, if IE cannot access this location, or if the Codebase tag is not present, there is a list of alternate locations stored in the following registry value:

 \CurrentVersion \Internet Settings\CodeBaseSearchPath

The default data in this registry value is:


The first entry tells IE to always use the URL provided in the CODEBASE HTML tag first to download the code. If that fails then IE will step through the list of alternate sites listed in the CodeBaseSearchPath until it finds the code or runs out of places to check.

For organizations that want to permit the use of ActiveX controls, but do not want to allow users to download code directly from the Internet, this CodeBaseSearchPath can be customized to something like the following:


Removing the initial "CODEBASE" keyword prevents users from downloading any code from the Internet, while substituting the other locations with an internal site allows the administrators to specify which controls are downloaded. The URL specified in the CodeBaseSearchPath will receive an HTTP POST request with data in the following format and respond with the object to install and load.

CLSID={class id}

Additional information on how this request should be processed is available at .

The sites that receive and process requests for objects are called Object Stores. When implemented on top of an IIS web server, these stores could also be configured to authenticate the user prior to allowing the download of the code. For instance, specific users within your enterprise could be permitted to download controls to their machines that you may not want all users to access.

Once a control is downloaded and installed on the system, it is then available to all users that log on to the system. However, Internet Explorer provides other means to control objects after they have been installed.

The "Safe for" Flags & IObjectSafety

Once a control is installed on a system any HTML web page can attempt to load it using the OBJECT tab. However, many applications that the user may install are not intended to be loaded or scripted within web pages, and doing so would allow a malicious web site to damage the user's machine. To prevent this, there are two flags that can be set on each COM object registered on the workstation that determine the action a web page can take with this control. These flags are referred to as "Safe for Initialization" and "Safe for Scripting" and are usually set by the control when it is installed. The following quotes from the MSDN Web Workshop describe the assertion made by setting these flags:

"If you mark your control as safe for initializing, you are asserting that no matter what values are used to initialize your control, it won't do anything that would damage a user's system or compromise the user's security."

"If you mark your control as safe for scripting, you are asserting that your control won't do anything to damage a user's system or compromise the user's security regardless of how your control's methods and properties are manipulated by the Web page's script. In other words, it has to accept any method calls (with any parameters) and/or property manipulations in any order without doing anything bad."

It is not recommended that you change these settings to mark a control safe that the author had not marked as safe. However, these flags may be used to further restrict controls that you believe pose a security risk to your users. These flags can be set directly in the registry by creating the following keys:

[HKEY_CLASSES_ROOT \CLSID{CLSID of control}\Implemented 

Marks a control as "safe for scripting"

[HKEY_CLASSES_ROOT \CLSID{CLSID of control}\Implemented 

Marks a control as "safe for initialization"

By removing the appropriate bolded key above then a control can will no longer for marked as safe for the operation.

Another method for determining what operations a control is safe for is to query the IObjectSafety interface, if the control supports it. A control can chose to implement IObjectSafety in addition to or instead of the registry keys above. Prior to loading the control and prior to checking the registry keys Internet Explorer will query the IObjectSafety interface on the object to see if the control supports it. If the control supports this interface then IE will use the interface to query the safe operations of the control instead of the registry keys. The control may choose to implement the IObjectSafety interface by simply querying the above registry keys or it may choose to tailor its security depending on the zone it is in or the current IE security policy settings.

The Internet Explorer security settings also allow the user or administrator to override the behavior of the "Safe for" flags depending on the security zone in the following manner:

Permit the initialization and scripting of controls even though they are not marked as safe for such operations.

Disable the scripting of controls even though they are marked as safe for scripting.

For instance, you might decide to permit the initialization and scripting of a control not marked as safe in the Trusted Sites zone because you know the web authors of those sites would not attempt any malicious actions on your workstation. However, in the Restricted Sites zone you might decide to prevent the scripting of controls, even though they are marked safe. By using these measures instead of directly manipulating the "safe for" flags, you can continue to rely on the "safe for" flags as configured by the component author in the Internet and Local Intranet zones.

"Administrator Approved"

Within each IE security zone there is an option to only run controls that have been "Administrator Approved". While settings such as Authenticode are used to control the download of code to the workstation, the "Administrator Approved" setting can enforce security policy after a control has already been installed. The list of controls that are permitted to run is stored in the registry in the following value:

[HKEY_CURRENT_USER \SOFTWARE \Policies \Microsoft \Windows 
\CurrentVersion \Internet Settings\AllowedControls]

The bolded text in quotes is the CLSID of the object that you wish to allow to run. Only those values with a DWORD value of 00000000 will run once the "only run administrator approved controls" option is set. Note that this setting is stored in the HKEY_CURRENT_USER hive of the registry and is therefore configurable on a per user basis. Command line tools such as regedit can be used as a part of a logon script or distributed via SMS to configure the permitted controls for a user.

On Windows NT and Windows 2000-based machines this registry key normally has an access control list (ACL) that prevents users from changing the list of approved controls. However, the Windows 9x platform does not support registry ACLs and therefore a user could change the approved control list by directly manipulating the registry. The Windows 9x system policy mechanisms can be used to reset the registry values at logon and prevent the use of the registry editor tool.

While it is possible to set the list of approved controls directly via the registry, it is far easier to use the Internet Explorer Administration Kit (IEAK). When the IEAK is installed on the administrator's machine, the list of controls that can be marked as approved is created from the controls already present on the machine. To manually change this list edit the axaa.inf file in the IEAK installation directory.

On Windows 2000 machines in a domain the configuration of "Administrator Approved" controls can be distributed to users using Group Policy Objects in the Active Directory™ service. Like any Group Policy settings, these can be applied domain wide, site wide, or to users in specific Organizational Units.

The "Kill Bit"

On occasion, a control is installed that poses such a risk that it should not be accessible from within the browser under any circumstances. Simply marking the control as "unsafe for initialization" is not sufficient to ensure that the control will never load, even after a re-install scenario. This is where the "kill bit" comes in and it cannot be overridden with any of Internet Explorer's zone configurations.

The "kill bit" is a registry value that contains the CLSID of all controls that IE will not load. To set the "kill bit" on a specific control you must create or locate the following registry key:

[HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Internet Explorer
\ActiveX Compatibility\"{8856F961-340A-11D0-A96B-00C04FD705A2}"]
"Compatibility Flag"=dword:00000400

The bolded text in quotes is the CLSID of the object that you are setting the kill bit for and the DWORD value of 00000400 prevents IE from loading the control.

Office 97 Macro Virus Protection

Microsoft Office 97 first introduced configurable macro security settings designed to reduce the spread of macro or embedded VBA viruses. The Office 97 macro virus protection consisted of three security settings defined as follows:

Low – Macros embedded within Microsoft Word documents would run without user intervention. This was the same behavior as in previous versions of Microsoft Word and offers no additional security against viruses.

Medium – The user is prompted when a document they are opening contains an embedded macro. They are given the option to not open the document, open the document with the macros disabled, or open the document with the macros enabled. This approach offers the most flexibility but assumes that the user is sufficiently knowledgeable to know whether the document should contain a macro.


High – Any macros embedded in the document are automatically disabled. In organizations where macros are used to automate tasks, this is not an acceptable option.

Further information on Office 97 macro security is available in the white paper at;en-us;310365&sd=tech

Office 2000 Signed Macros

Microsoft Office 2000 improves upon the macro protections in Office 97 by supporting the ability to digitally sign embedded macros. Office 2000 also offers three levels of security that are very similar to the Office 97 levels.

Low – Macros embedded within Microsoft Word documents will run without user intervention. This is the same behavior as in previous versions of Microsoft Word and offers no additional security against viruses.

Medium – The user is prompted when a document they are opening contains an embedded macro that is not signed by a "trusted source"2 . They are given the option to not open the document, open the document with the macros disabled, or open the document with the macros enabled. If the macro is signed then Office 2000 will also display information about the signer to the user. The user may also choose to add the signer's certificate as a "trusted source". This option offers the most flexibility but still places the responsibility for the trust decision on the end user.


High – This is now the default security level in Office 2000. Any macros embedded in the document that are not signed by a trusted source are automatically disabled. This option offers the most security, but requires that all macro developers sign their scripts. This setting also requires the management of the "trusted sources" list on clients.

Microsoft provides tools for deploying and managing the "trusted sources" list for signed macros. The Custom Installation Wizard (available in the Office 2000 Resource Kit at ) enables the administrator to specify these security settings for their users when Office 2000 is installed. The list of trusted sources is stored as a hash of the certificate in the registry key:

HKEY_CURRENT_USER \Software \Microsoft \VBA \Trusted

--- Or ---

HKEY_LOCAL_MACHINE \Software \Microsoft \VBA \Trusted

If a list of trusted sources is present in the HKEY_LOCAL_MACHINE hive then this list will be used by all users that log on to that machine and the list stored in HKEY_CURRENT_USER will be ignored. For corporate users running on Windows NT or Windows 2000, it is recommended that the list of trusted sources be placed in HKEY_LOCAL_MACHINE and an Access Control List placed on the entry to prevent the user from editing the list. Macro developers within the company may need a special configuration that allows them to run and test macros signed with a development certificate or to have their security configuration set to low or medium. Developers should not sign code under development with the same certificate used to sign production code.

Many organizations have put off deploying signed macros or other Authenticode technologies because they believe it requires a large and complicated Public Key Infrastructure. However, it is important to recognize that signing scripts and mobile code does not require that each user have a digital certificate. Rather, the only people that need certificates are the people developing the scripts or some approval authority that can sign code prior to deployment. This can easily be accomplished by purchasing a single code-signing certificate from a trusted commercial Certificate Authority or you can issue your own certificates using the Certificate Services in Windows 2000. More information on certificate requirements for code signing is available in the Authenticode section above.

Further information on the Office 2000 macro security is available in the white paper at

Outlook Attachment Security

One thing the rapid spread of the "ILOVEYOU" virus demonstrated was that many users do not understand the risk in running programs they receive in e-mail. Furthermore, even the more savvy users may not recognize the myriad attachment types that could potentially contain executable content. Following the discovery of the Melissa virus Microsoft released in May of 1999 the Outlook attachment security patch for each version of Microsoft Outlook. This patch was designed to not only educate users about the risks of e-mail attachments, but also to eliminate the guesswork about which attachment types were dangerous. The original patch had a fixed list of content that was considered potentially dangerous and would prompt the user with a dialog like the following whenever the user attempted to launch the attached program from within Outlook.

This dialog not only explained the potential danger, but also forced the user to save the attachment to disk and then go back and open it. This was designed to make the user reconsider their actions by preventing the common reaction of double-clicking any attachment in e-mail to see what it is.


Outlook 2000 Service Release 1 (SR-1) shipped with this patch as an integrated feature. Furthermore, SR-1 included the ability to add or remove extensions from the list of extensions that should invoke this dialog. This is accomplished by adding the appropriate value to the following registry key:

HKEY_LOCAL_MACHINE \Software \Microsoft \Office \9.0\Outlook\Security
Name: AddWarningFileTypes
Type: REG_SZ
Data: XYZ;ABC 
Name: RemoveWarningFileTypes
Type: REG_SZ

Note: Extensions should be separated by a semicolon and should not include the leading period (.) character.

Further information on the Outlook attachment security patch as well as how to configure Outlook 2000 SR-1 attachment security can be found in the following Microsoft Knowledge Base articles:;en-us;259228&sd=tech;en-us;235309&sd=tech

Outlook Security Update II

In response to the "ILOVEYOU" virus Microsoft released in June 2000 a second Outlook security patch for customers who wanted to place greater restrictions on the handling of e-mail attachments and the programmatic use of Outlook. This patch makes the following changes to the behavior of Microsoft Outlook 98 and Outlook 2000 once installed:

E-mail attachment security prevents users from accessing several file types when sent as e-mail attachments. Affected file types include executables, batch files, and other file types that contain executable code often used by malicious hackers to spread viruses. The patch defines two levels of attachment security. Level I attachments are hidden from the user by Outlook; users cannot access them. instead, a banner is placed in the message window.


Level II attachments cannot be invoked directly from the message and must be saved to disk first - this is the same functionality provided by the first Outlook attachment security update.

Object Model Guard prompts users with a dialog box when an external program attempts to access their Outlook Address Book or send e-mail on their behalf, (which is how viruses such as ILOVEYOU spread). This feature is designed to prevent the spread of viruses via e-mail but it also means that the user must be present to respond to the prompt when applications attempt to programmatically access Outlook - such as when synchronizing a handheld device with Outlook.


Heightened Outlook default security settings increase the default Internet security zone setting within Outlook from "Internet" to "Restricted Sites." In addition, active scripting within restricted sites is disabled by default. These security features help protect users from many viruses that are spread by means of scripting.

To allow customers to further refine their security policy this update also provides a server side mechanism to customize the restrictions placed on users. For organizations that use Microsoft Outlook in combination with Microsoft Exchange server the Outlook security update settings can be stored in an Exchange public folder3. When Outlook starts, it will query this public folder to obtain the customized settings including changes to the Level I and Level II attachment lists and whether or not to prompt, allow, or deny programmatic access to Outlook from applications.

Further information on the Outlook attachment security patch as well as how to configure Outlook 2000 SR-1 attachment security can be found at the following location:

Putting It All Together

Since each environment is different, there isn't a single set of recommendations that's appropriate for all customers. However, certain recommendations can be made that will offer benefit to anyone.

Install the first Outlook attachment security patch or Outlook 2000 SR1 - This patch will ensure that users are made aware when an attachment in e-mail poses a security risk and prevent them from immediately executing it. This patch combined with user education can dramatically reduce the risk of attacks such as the "ILOVEYOU" virus.

Change Outlook HTML mail to run in the Restricted Sites zone – The use of HTML formatted mail messages offers the ability to include rich formatting that is understood by a wide variety of clients. Therefore, interpreting mail messages in the Restricted Sites zone will provide an appropriate level of security for the application. Ensure that scripting and ActiveX controls are disabled in the Restricted Sites zone.

Upgrade to Microsoft Office 2000 – The default settings in Office 2000 disallow running unsigned macros. Upgrading all of your users to Office 2000 can prevent the spread of VBA viruses embedded within Word, Excel or PowerPoint.

Have a mechanism in place to react to new threats – Security requires constantly adapting to new threats. Having some mechanism in place to deploy updates to client machines quickly is critical to maintaining security. This mechanism can be as simple as a common logon script that can be used to deploy registry updates or could use more robust mechanisms such as Windows 2000 Group Policy, Systems Management Server, or the IE Administration Kit.

Define different levels of security commensurate with a person's job – For instance, certain users may have the need and expertise to make trust decisions on their own. They may have gone through training to better understand the implications of downloading a particular control and need the flexibility this provides. Other users may be prime targets for attack or hold higher access privileges and could do a great deal of damage if attacked. These accounts should have more restrictive security settings in place.

Controlling Code Download

Below is one possible framework for using the technologies described in this document to categorize the control of code download via the web browser.

Level 1 – Trust All Controls

The first level is the one adopted by most organizations and consequently tends to concern security professionals. Users are permitted to download and run code from any source and the ultimate trust decision lays with the end user on whether or not to install a particular control. This is analogous to allowing users to install any software they can find or purchase.

Level 2 – Trust Only Signed Controls

Implementing Level 2 means setting the IE security zones to only download and install objects that are digitally signed. The presence of a digital signature from a certificate issued by a trusted CA gives you the ability to determine the author of the code should something malicious occur. The presence of a digital signature on the malicious code may also offer some legal proof of the origin of the code should you decide to seek legal action. This is analogous to only allowing users to install software purchased from a local software retailer.

Level 3 – Trust Only Signed Controls from Specific Vendors

With this level, you are making general statements about your relationship with certain vendors. You are setting the Authenticode polices to only download content from authors whom you believe to be trustworthy based on past experience or some sort of formal process. This could be as simple as first checking the vendor's Dunn & Bradstreet number or obtaining references. This same model could also be used to enforce the signing of all internally developed objects prior to deployment. This level maps to the software purchase requirements used by most large organizations.

Level 4 – Trust Only Specific Controls

Level 4 introduces the concept of an internal object repository to redirect object download requests to. At this level the security settings from level 3 are still in place to restrict downloaded code to only specific authors. In addition though, the CodeBaseSearchPath is modified on clients so that they will not fetch code objects from anywhere but designated internal sites. The external sites will continue to function normally as long the control they are trying to instantiate is permitted by policy on housed on this internal repository.

This hosted object repository can consist of little more than an IIS web server that processes the requests for objects from clients and returns the desired object if permitted by policy. The objects hosted on this repository can maintain their original digital signature or be resigned by an internal authority if desired. This model brings the level of specificity for permitted code download down to the individual object or application rather than trusting all code from specific vendors.

1 An attachment could be included but would need to be extracted into a known directory (or simply "launched") to be scriptable from the HTML mail message. The IE security model is designed to prevent this from happening.

2 The trusted source refers to a single signing certificate that is trusted; it does not imply trust for any certificates issued by a certain Certificate Authority.

3 Microsoft has also worked with Lotus, HP, and Novell to provide them with information to allow them to incorporate the same features in their mail server products.