19.1. Understanding How VBA Implements Security

Macros and user forms contain computer programs, albeit usually rather small ones. But because macros like any other computer program can access the user's hard drive and manipulate other sensitive areas of the computer, macros can do damage.

Office 2007 and Vista include a variety of security features designed to protect the user from malicious code — macro, virus, Trojan horse, or whatever. But some security features are specific to Office documents and the macros and user forms they can contain.

Note that an evil macro can do its damage automatically; it's not necessary for the user to deliberately launch it from the Macros dialog box, or from within the Visual Basic Editor. Some specially named procedures automatically launch themselves. For example, any code in a Document_Open Sub executes when its host document is merely opened:

Private Sub Document_Open()

Malicious code can enter a user's computer in three vehicles: macros, ActiveX controls, and add-ins. Microsoft provides users with various approaches to VBA security, including the following:

• Certain types of Office documents that simply cannot contain any embedded macros at all.

• Documents that are loaded from a trusted area on the hard drive.

• Trust center settings the user can specify, such as completely preventing the execution of any ActiveX controls, macros, or add-ins, without even notifying the user. Alternatively, the user can be prompted for permission before potentially dangerous code is allowed to be loaded.

• A list of user-modifiable "trusted publishers" — companies whose documents are considered safe.

• The ability to digitally sign your own documents or templates, thereby making you a "trusted publisher."

New in Office 2007 are documents that simply cannot contain any macros or other potentially malicious code. By default, a new Word document is of the .docx type, not the .docm (macro-enabled) type. In other words, a document must be deliberately created as a macro-enabled document. And because it must have a .docm file extension, everybody else (including Word when opening the document) knows that it contains possibly dangerous code. Administrators can use Group Policy to enforce rules concerning which file types are permitted. But the default .docx file type is free of potentially risky executables.

Other Office 2007 applications also have pairs of macro-disabled, macro-enabled file types. Excel has .xlsx and .xlsm files, and PowerPoint has .pptx and .pptm files.

To secure an application against rogue VBA code, you can use the new Trust Center to choose the level of security that you want the application to use when running VBA code. Press Alt+F, I; click the Trust Center button in the left pane; and click the Trust Center Settings button.

You can also specify which sources to trust and how much to trust them. A trusted source might be someone who works for the same company as you, or someone who has a digital certificate from a third party you trust, such as the VeriSign certification authority. Because you (in this example) trust VeriSign, you trust the third party to whom VeriSign has issued a digital certificate.

To establish that your own code is fine for the applications to trust, you sign a document or template project that contains customizations or macro project items (code modules, class modules, or user forms) with a digital signature generated by a digital certificate that uniquely identifies you or your company. This chapter shows you this technique first, because it sets the stage for specifying the level of security to use.

To secure your code, you can lock a macro project with a password so that nobody can open the code. Doing so serves both to prevent anyone from tinkering with your code and either stopping it from working or rendering it harmful, and to protect your intellectual property: if nobody can see your code, they can't steal your ideas. The section "Locking Your Code" shows you how to do this.