Security Notes for Microsoft Office Solution Developers

About Setting Microsoft Office 2003 Security in a Testing Environment Microsoft Office 2003 Macro and Add-in Security Settings Matrix
About Enabling "Trust all installed add-ins and templates"
About Modifying the Microsoft Windows Registry
About Making Microsoft Windows Application Programming Interface (API) Function Calls
About Digital Code Signing
About Secure Deployment of Managed COM Add-ins in Microsoft Office 2003
About Automating the Visual Basic Editor
About Passwords
About Microsoft Office Outlook 2003 Security Settings

About Setting Microsoft Office 2003 Security in a Testing Environment

To install and run an unsigned COM add-in or Microsoft Visual Basic for Applications (VBA) macro, the security settings in the Security dialog box (Tools menu, Macro submenu, Security command) must be set to Medium, with the Trust all installed add-ins and templates check box cleared. It is strongly recommended that you do this only in a testing environment. After you have completed your testing, set the security level back to Very High or High.

Caution  By setting the security level to Medium, with the Trust all installed add-ins and templates check box cleared, users will have the choice to either enable or disable unsigned COM add-ins and VBA macros when they are prompted. If your security level is set to Very High or High, with the Trust all installed add-ins and templates check box cleared, all unsigned COM add-ins and VBA macros will be disabled automatically. Therefore, it is strongly recommended that all users keep their security levels set to Very High or High with the Trust all installed add-ins and templates check box cleared.

Microsoft Office 2003 Macro and Add-in Security Settings Matrix

The following table lists the available Microsoft Office 2003 security settings, along with their corresponding behaviors, in the Security dialog box (Macros submenu, Tools menu).

Office 2003 macro and add-in security setting options

Note   The availability of, and options within, the Security dialog box vary depending on the specific Office application. Additionally, specific Office applications silently load signed add-ins and macros only from specific directories, along with registered COM add-ins and smart tags recognizers.

For more information on these settings and on the other issues discussed in this topic, search for "Office macro security" in the Microsoft Developer Network (MSDN) Library.

About Enabling "Trust all installed add-ins and templates"

The Trust all installed add-ins and templates check box is commonly misunderstood. By default it is enabled, but Microsoft recommends that customers with high security requirements disable it, and this is a good "defense in depth" approach.

If you have no need to run unsigned personal macros or unsigned COM add-ins, you should disable this option. When Office application security level is set to Very High or High, with the Trust all installed add-ins and templates option disabled, all add-ins and templates that are not signed will automatically be disabled. If the add-ins and templates are signed using a certificate not listed in the Trusted Sources list, a user will be prompted to trust the source in order to allow the add-in or template to run.

Enabling the Trust all installed add-ins and templates check box will allow all COM add-ins that have been installed in the registry (which requires administrative privileges) or VBA macros that are stored in your personal or workgroup locations to run, regardless of whether they are signed or not. It should also be noted that end-users do not need administrative privileges to install VBA macros to certain template and startup folders. Examples of these locations in Office Word 2003 are:

• \Documents and Settings\<user name>\Application Data\Microsoft\Word\STARTUP
• \Documents and Settings\<user name>\Application Data\Microsoft\Templates

With the Trust all installed add-ins and templates option enabled, you can be attacked if you download, register, and run a malicious COM add-in or if you run a malicious template from someone else.

If you decide to run personal VBA macros or to run locally installed COM add-ins, and you don't want to purchase a digital certificate, but you want to disable the Trust all installed add-ins and templates option, here are the available alternatives:

• Sign your personal VBA macros or locally installed COM add-ins using a test certificate created using either selfcert.exe or Authenticode tools, depending on whether it's a macro or add-in. This way, you can keep your security settings set to Very High or High, with the Trust all installed add-ins and templates option disabled. For more information on how to generate a test certificate, refer to the About Digital Code Signing section below.
• Set your Office application security level to Medium with Trust all installed add-ins and templates disabled. With these security settings, you will be prompted to enable or disable a COM add-in or VBA macro when the application is launched. It's strongly recommended that you use these settings only in a testing environment.

About Modifying the Microsoft Windows Registry

Modifying the Microsoft Windows registry in any manner, whether through the Registry Editor or programmatically, always carries some degree of risk. Incorrect modification can cause serious problems that may require you to reinstall your operating system. It is always a good practice to back up a computer's registry first before modifying it. If you are running Microsoft Windows NT, Microsoft Windows 2000, Microsoft Windows XP, or Microsoft Windows Server 2003, you should also update your Emergency Repair Disk (ERD).

For information about how to edit the registry, view the "Changing Keys and Values" Help topic in the Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Information" topics in the Registry Editor (Regedt32.exe).

About Making Microsoft Windows Application Programming Interface (API) Function Calls

Before calling Microsoft Windows API functions, you should understand how arguments and data types are handled by the Windows API DLLs. Incorrectly calling Windows API functions may result in invalid page faults or other unexpected behaviors. For more information on calling Windows API functions, see the topic "The Windows API and Other Dynamic-Link Libraries" in the Microsoft Office 2003 Developer Online Documentation or the Microsoft Developer Network (MSDN) Library.

About Digital Code Signing

Many security-conscious users and administrators set their Microsoft Office 2003 security levels to Very High or High with the Trust all installed add-ins and templates check box cleared (located in the Security dialog box, Macro submenu, Tools menu), which is highly recommended. With these settings, a signed and trusted COM add-in or VBA macro will be loaded, and a non-signed COM add-in or VBA macro will be disabled automatically. The only time a user will be prompted to either enable or disable a COM add-in or VBA macro is when a COM add-in or VBA macro is signed but the software publisher is not included in the Trusted Sources list.

Microsoft Authenticode technology allows software publishers to digitally sign executable (EXE) files, ActiveX control (OCX) files, cabinet (CAB) files, and dynamic-link library (DLL) files. For a step-by-step guide on how to digitally sign a COM add-in using Microsoft Authenticode technology, search for "digital code signing" in the MSDN Library.

About Secure Deployment of Managed COM Add-ins in Microsoft Office 2003

To comply with Office 2003 security, managed COM add-ins (COM add-ins targeting the common language runtime) must be digitally signed, and users' security settings should be set to their highest levels. Additionally, you will need to incorporate into your managed COM add-in project a small unmanaged proxy called a shim in order to avoid unexpected security warnings. For details, search for "deployment managed add-ins" in the MSDN Library.

About Automating the Visual Basic Editor

In Office 2003, when calling the features of the Microsoft Visual Basic for Applications Extensibility object model, you may receive an error message that programmatic access to the Visual Basic project is not trusted. To prevent this message from appearing, point to Macro on the Tools menu, and then click Security. On the Trusted Sources tab, check the Trust access to Visual Basic Project box. By checking this box, macros in any documents that you open can access the core Microsoft Visual Basic objects, methods, and properties, which represents a possible security hazard. The default behavior in Office 2003 is to not allow macros to programmatically access the Visual Basic object model. The recommended behavior is to check the Trust access to Visual Basic Project box only for the duration of a macro that accesses the Visual Basic object model. The Trust access to Visual Basic Project box should be unchecked after the macro has finished running.

About Passwords

Avoid using hard-coded passwords in your applications. If a password is required in a procedure, request the password from the user, store it in a variable, and then use the variable in your code.

Always use strong passwords. Strong passwords should contain:

• Both lowercase and uppercase characters.
  
• Numbers.
  
• Symbols (such as #, $, %, and ^).
  
• At least eight characters.

Strong passwords should not contain patterns, themes, or words found in a dictionary.

Examples of strong passwords include:

• $tR0n9p@$s
  
• G80dn[s$M4!

Note  You should change your password frequently; for example, every one to three months.

About Microsoft Office Outlook 2003 Security Settings

COM Add-ins Using Default Security

In Microsoft Office Outlook 2003, all COM add-ins that run on a computer which is not configured to obtain security settings from a Microsoft Exchange Server are considered trusted by default. This implies that the add-ins that run on clients that are not Exchange clients and the add-ins that use default security in Exchange environments are trusted automatically. As in Outlook 2002, Office Outlook 2003 trusts only the main Application object that is passed to the OnConnection event of the add-in.

COM Add-ins Using Security Settings from an Exchange Server

There has been no change in the way Office Outlook 2003 trusts COM add-ins in an Exchange environment when the security settings are obtained from the Exchange server. An add-in will be considered trusted only if it’s registered in the Security Settings folder. Again, as in Outlook 2002, Office Outlook 2003 trusts only the main Application object that is passed to the OnConnection event of the add-in.

Improvements to Outlook Object Model Guard and the Impact

Office Outlook 2003 inherits the Outlook 2002 object model guard behavior and, in addition, blocks code that attempts to access the Body and HTMLBody properties of various Outlook items. This allows users to verify that the program or add-in accessing the Body and HTMLBody properties of these items is trustworthy, before they allow access to the contents of the items. Although this change forces the display of security warnings in existing COM add-ins that access the Body or HTMLBody properties of items, this will help prevent malicious code from running unknown to the user.

You can avoid the display of security warnings by deriving all objects, properties, and methods from the Application object passed to the OnConnection procedure of the add-in. Office Outlook 2003 trusts only the Application object passed to the OnConnection procedure of the add-in. If you create a new Application object -- for example, by using the CreateObject method -- that object and any of its subordinate objects, properties, and methods will not be trusted and the blocked properties and methods will raise security warnings.

New Object Model Blocks in Office Outlook 2003

The following are the additional properties that have been blocked in Office Outlook 2003:

• The IMAddress property of a ContactItem object.
• The HTMLBody property of a MailItem object.
• The Body property of the following objects: ContactItem, MailItem, PostItem, AppointmentItem, TaskItem, TaskRequestItem, TaskRequestAcceptItem, TaskRequestDeclineItem, TaskRequestUpdateItem, DistListItem, JournalItem, MeetingItem, ReportItem, RemoteItem, NoteItem, or DocumentItem.

Also, if you use a third-party add-ins, custom solutions, or other programs that integrate with Office Outlook 2003, you may receive one or more of the following warnings:

• "A program is trying to automatically send e-mail on your behalf. Do you want to allow this? If you unexpectedly receive this message, it may be caused by a virus, and you should choose No."
• "A program is trying to access e-mail addresses you have stored in Outlook. Do you want to allow this? If you unexpectedly receive this message, it may be caused by a virus, and you should choose No. "

These warning messages are commonly associated with software that is designed to synchronize Outlook data with handheld computers, but may occur with any type of add-in or custom solution.