Different types of signed and unsigned macros react differently to the four levels of macro security settings — Very High, High, Medium, and Low. Users can change these settings through the Security Level tab in the Security dialog box (Tools menu, Macro submenu) of most Microsoft® Office 2003 applications that help to enforce macro security.

In all cases Low security presents no prompt to the user, and all macros are allowed to run. When macro security is set to Low, certificates of trust attached to macros are not examined by the system and are not presented to the user for acceptance. Since the user is never prompted to accept or reject these certificates, they are not posted to the trusted Trust Publishers store for Office applications.

Only when macro security is set to Medium or High and a user agrees to trust a certificate can a certificate be added to the trusted Trust Publishers store. Certificates can also be added by the administrator in a couple of ways — when deploying Office with the certificate of trust embedded in a transform, or by using the Active Directory® directory service to deploy the certificate to all users who need it.

At Very High security, executables can be run if two requirements are met — the executable is stored in a specific trusted location on the local hard disk, and the Trust all installed add-ins and templates option in the application is set to checked. When this option is not set to checked, VBA macros, COM add-ins, or Smart Tag dynamic-link libraries cannot run, even if they are signed with a valid certificate. Setting macro security to Very High and setting Trust all installed add-ins and template to not checked is one way to restrict a user to running only the features installed with the core Office applications; all extensions to Office using VBA or COM-based code are disabled.

The following list presents the valid trusted folders each application will use when the Trust all installed add-ins and templates option is set to checked. These folders are examined to determine whether a VBA project is installed in the specified location (with the exception of a location defined by the add-in manager for each application):

Microsoft Office Access 2003

No pre-defined trusted location.

Microsoft Office Excel 2003

<Documents and Settings>\<user name>\Application Data\Microsoft\Excel\XLSTART

<Program Files>\Microsoft Office\Office11\XLSTART

Microsoft Office Outlook® 2003

No pre-defined trusted location.

Microsoft Office PowerPoint® 2003

No pre-defined trusted location.

Microsoft Office Project 2003

<Program Files>\Microsoft Office\Office11\<LCID>

Microsoft Office Publisher 2003

No pre-defined trusted location.

Microsoft Office Word 2003

Templates folder — <Documents and Settings>\<user name>\Application Data\Microsoft\Templates

Startup folder — <Documents and Settings>\<user name>\Application Data\Microsoft\Word\STARTUP

Workgroup Template folder — No pre-defined trusted location

Each of these folders can be defined in the Tools | Options (dialog) | File Locations (tab) dialog. The Templates, Startup, and Workgroup Template folders are all considered a trusted source for opening files. They can each be modified to point to a different folder or drive. All of these folders should be protected in some way by using file- and folder-level permissions. A common mistake for many users and administrators is to define a new location but not to apply some degree of file- and folder-level protection to the new location. Any subsequent virus submitted to a computer that bypasses security settings could conceivably save into one of these locations and bypass the security of Office applications.

---

 Note    The STARTUP folder of Word is where an administrator could place a macro that automatically loads and runs when Word is started. The XLSTART folder used by Excel performs the same way.

---

The following list summarizes the effect High and Medium security settings have on signed and unsigned macros. The list does not present the Low security option because Low security has the same effect in all cases. Very High macro security is limited to only macros stored in a specific location on the local hard disk; signing of the macro is irrelevant in this case, therefore it is not listed in the following material.

---

 Note    New to this release of Office is a component that checks all XML files that have references to XSLs (XML transforms) for possible script. If script is found, it is disabled if the macro security is set to High. If the macro security level is set to Medium, the user is prompted as to whether to run the script. If macro security is set to Low, the script is run.

---

• Unsigned macros

  High — Macros are disabled.

  Medium — User is prompted to enable or disable macros.

• Signed macros from a trusted source with a valid certificate

  High and Medium — Macros are enabled.

• Signed macros from an unknown source with a valid certificate

  High and Medium — Information about the certificate is displayed. Users must then determine whether they should enable any macros based on the content of the certificate. To enable the macros, users must accept the certificate.

  ---

   Note    A network administrator can lock the list of trusted sources and prevent a user from adding a certificate of trust to the list, thereby disabling all macros.

  ---

• Signed macros from any source with an invalid certificate

  High and Medium — User is warned of a possible virus. Macros are disabled. The user cannot trust the certificate.

• Signed macros from any source where validation of the certificate is not possible because the public key is missing or an incompatible encryption method was used

  High — User is warned that certificate validation is not possible. Macros are disabled.

  Medium — User is warned that certificate validation is not possible. User is given the option to enable or disable macros.

• Signed macros from any source, in which the macro was signed after the certificate had expired or was revoked by the certificate authority

  High — User is warned that the certificate has expired or was revoked. Macros are disabled.

  Medium — User is warned that the certificate has expired or was revoked. User is given the option to enable or disable macros.

Further information about macro security levels is available in the Help for each of the respective Office applications that enforce macro security.

Programming-related security issues

Prior to Office XP, when a macro was started and attempted to run another macro by using an internal call to that macro, that macro was not challenged by macro security — regardless of whether the macro was signed or trusted. One of the assumptions behind allowing this was that a trusted macro would only make a call to run other safe macros. The primary reason this was done was so any calls to other macros in a procedural execution of chained macros would not halt execution.

Unfortunately, when macros are run unchallenged, it is the same as running them without security. If a macro marked as safe calls and executes a bad macro or an infected application, the results could be harmful.

To address this issue, a new security method was added to all Visual Basic® for Application (VBA) application objects called AutomationSecurity. This method can be used with the Application object for each Office application, allowing programmers a means of controlling how security is handled when a macro calls another macro or external program.

Example:

Application.AutomationSecurity=msoAutomationSecurityByUI

The values for use with this method are:

• msoAutomationSecurityLow

  Sets the macro security to Low for this application; macros are run without checking their certificate for authenticity; this is not recommended.

• msoAutomationSecurityByUI

  Sets the macro security to the same level as is currently set in the user interface for the application (as found in the Security dialog); this is recommended.

• msoAutomationSecurityForceDisable

  Sets the macro security level to High; all macros must be from a trusted source in order to run. This setting is recommended but may cause confusion if users expect the security to be at the same level as that set in the user interface.

It is highly recommended that prior to using any form of the Open method, that Application.AutomationSecurity be set to msoAutomationSecurityForceDisable or msoAutomationSecurityByUI unless a good reason for setting it otherwise is identified. Choosing to set AutomationSecurity to msoAutomationSecurityLow should be done only if it can be assured that the content of the file to open will not introduce a virus.

For programmers who need to instruct Office applications to open files or start applications or utilities from a command embedded within a macro or program, it is recommended to set AutomationSecurity to msoAutomationSecurityByUI prior to opening a file or starting an executable to conform to the security level set for the application by the user.

High security and Excel 4.0 macros

If you plan to use macros created using Excel 4.0 Macro Language (XLM) with Microsoft Office Excel 2003, you need to add a registry entry to enable them if macro security is set to High. All Office applications have macro security set to High by default when installed, unless a lower security level was specified in a transform (MST file) or Office profile settings file (OPS file).

This registry entry is necessary because Excel 4.0 XLM macros cannot be digitally signed and, therefore, cannot load when High macro security is enabled. (High security requires a macro to be signed with a valid certificate from a trusted source.)

Because some Excel add-ins were created using XLM, you may need to add the following registry entry to each user's computer to allow the macros to run. The same is true for add-ins created from XLM macros you want to run as exceptions under High macro security in Excel. To add this entry, you can use a transform, configuration maintenance file (CMW file), or REG file.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Excel\Security

Value name: XLM

Value type: DWORD (integer)

Value data: [ 0 | 1 ]

Creating and setting the XLM registry value to 1 allows users to load XLM macros. Setting this value to 0 or removing the registry entry returns Excel 2003 to its default behavior of not allowing XLM macros to run in High security.

When this registry entry is added and set to 1, users are warned about XLM macros when they attempt to open a workbook that contains these macros, and they are given the option to open the workbook and enable the use of macros. Users should run a virus check on any XLM macro before they enable it. Even though XLM macros are allowed through the High security check, the High security feature for all forms of macros (such as VBA macros) is still enabled.

Setting this registry entry allows for automatic and silent disabling of non-signed VBA macros; however, the XLM macros are evaluated as if Excel was set to Medium security. The administrator of the computer can force the running of signed and trusted VBA macros, but also allow exceptions for Excel 4.0 macros. If you set this registry entry, users should be educated about viruses that affect Excel 4.0 and how they are enabled if a workbook is opened.

---

 Note    Addition of this registry entry provides no indication to the user through the user interface that the system is running in a modified or reduced level of High security. Administrators should understand the risks of implementing this registry entry.

---