Export (0) Print
Expand All

Specific Security Considerations for Office Solutions

The security features provided by the Microsoft .NET Framework, Microsoft Office 2003, and the 2007 Microsoft Office system can help to protect against a variety of possible security threats in Visual Studio Tools for Office solutions. This topic provides recommendations to help you protect your Visual Studio Tools for Office solutions against possible threats, and also includes information about the behavior of Microsoft Office security settings on Visual Studio Tools for Office solutions.

Trusted Code Is Repurposed in a New, Malicious Document

An attacker could take trusted code that is meant for one particular purpose (for example, downloading personal information for an employment application) and reuse it in another document (such as a worksheet). The code does not know that the original document is not running, and may open up other threats (such as revealing personal information or executing code with increased privileges) when opened by a different user. Alternatively, the attacker can simply modify the data in the worksheet such that, when sent to the victim, it behaves unexpectedly. By changing the values, formulas, or presentation characteristics of a worksheet linked to code, it is possible for a malicious user to attack another user by sending a modified file. It may also be possible for users to access information they are not supposed to see by modifying values in the worksheet.

  • Since both the assembly location and the document location must have sufficient evidence to execute, this attack is not easy to mount. For example, documents in e-mail attachments or on untrusted intranet servers do not have enough permissions to run.

  • To make this attack possible, the code itself must be written in such a way that it makes decisions based on potentially untrustworthy data. An example is creating a worksheet that has a hidden cell that contains the name of a database server. The user submits the worksheet to an ASPX page, which attempts to connect to that server using SQL authentication and a hard-coded SA password. An attacker could replace the contents of the hidden cell with a different computer name and get the SA password. To avoid this problem, never hard-code passwords, and always check server IDs against an internal list of servers that are known to be good before accessing the server.

Recommendations

  • Always validate input and data, whether it comes from the user, the document, a database, a Web service, or any other source.

  • Be careful about exposing particular types of functionality, such as getting privileged data on behalf of the user and putting it into an unprotected worksheet.

  • Depending on the type of application, it might make sense to verify that the original document is running before executing any code (for example, verifying that it is running from a document stored at a known, secure location).

  • It might be a good idea to display a warning when the document opens if your application performs any privileged actions. For example, you might create a splash screen or a startup dialog box saying that the application will access personal information, and have the user choose to continue or cancel. If an end user gets such a warning from a seemingly innocent document, he or she will be able to quit the application before anything is compromised.

Code Is Blocked by the Outlook Object Model Guard

Microsoft Office Outlook 2003 and Microsoft Office Outlook 2007 can restrict code from using certain properties, methods, and objects in the object model. By restricting access to these objects, Outlook helps to prevent e-mail worms and viruses from using the object model for malicious purposes. This security feature is known as the Outlook object model guard. If an add-in attempts to use a restricted property or method while the object model guard is enabled, Outlook displays a security warning that enables the user to stop the operation, or enables the user to grant access to the property or method for a limited period of time. If the user stops the operation, Outlook add-ins created using Visual Studio Tools for Office will throw a COMException.

The object model guard can affect add-ins in different ways, depending on whether Outlook is used with Microsoft Exchange Server:

  • If Outlook is not used with Exchange, an administrator can enable or disable the object model guard for all add-ins on the computer.

  • If Outlook is used with Exchange, an administrator can enable or disable the object model guard for all add-ins on the computer, or the administrator can specify that certain add-ins can run without encountering the object model guard. Administrators can also modify the behavior of the object model guard for certain areas of the object model. For example, administrators can automatically allow add-ins to send e-mail programmatically, even if the object model guard is enabled.

For more information about the Outlook object model guard in Outlook 2003, including a list of the restricted methods and properties, see "What's New in Microsoft Office Outlook 2003 for Developers?" (http://go.microsoft.com/fwlink?LinkId=22731). For more information about Outlook security settings for Exchange administrators, see "Customizing Outlook 2003 to Help Prevent Viruses" (http://go.microsoft.com/fwlink?LinkId=24545).

NoteNote

Outlook 2007 introduces several changes to the behavior of the object model guard to improve the developer and user experience while helping to keep Outlook secure. For more information, see "Code Security Changes in Outlook 2007" (http://go.microsoft.com/fwlink/?LinkId=73429).

Minimizing Object Model Guard Warnings

To help avoid security warnings when you use restricted properties and methods, make sure that your add-in obtains Outlook objects from the following objects in your project:

  • For add-ins created by using Microsoft Visual Studio 2005 Tools for the Microsoft Office System (VSTO 2005), use the ThisApplication object.

  • For add-ins created by using Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System (VSTO 2005 SE), use the ThisAddIn.Application object.

Only Outlook objects obtained from these objects can be trusted by the object model guard. In contrast, objects that are obtained from a new Microsoft.Office.Interop.Outlook.Application are not trusted, and the restricted properties and methods will raise security warnings if the object model guard is enabled. For more information about the ThisApplication and ThisAddIn.Application objects, see Getting Started Programming Application-Level Add-ins.

The following code example from an add-in created by using VSTO 2005 displays a security warning if the object model guard is enabled. The To property of the Microsoft.Office.Interop.Outlook.MailItem class is restricted by the object model guard. The Microsoft.Office.Interop.Outlook.MailItem object is untrusted because the code gets it from a Microsoft.Office.Interop.Outlook.Application that is created using the new operator, instead of obtaining it from the ThisApplication object.

private void UntrustedCode()
{
    Microsoft.Office.Interop.Outlook.Application application =
        new Microsoft.Office.Interop.Outlook.Application();
    Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
        application.CreateItem(
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
        Microsoft.Office.Interop.Outlook.MailItem;
    mailItem1.To = "someone@example.com";
    MessageBox.Show(mailItem1.To);
}

The following code example from an add-in created by using VSTO 2005 demonstrates how to use the restricted To property of a Microsoft.Office.Interop.Outlook.MailItem object that is trusted by the object model guard. The code uses the trusted ThisApplication object, represented by the keyword Me in Visual Basic and this in C#, to get the Microsoft.Office.Interop.Outlook.MailItem.

private void TrustedCode()
{
    Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
        this.CreateItem(
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
        Microsoft.Office.Interop.Outlook.MailItem;
    mailItem1.To = "someone@example.com";
    MessageBox.Show(mailItem1.To);
}

NoteNote

If Outlook is used with Exchange, then obtaining all Outlook objects from ThisApplication (for VSTO 2005) or ThisAddIn.Application (for VSTO 2005 SE) does not guarantee that your add-in will be able to access the entire Outlook object model. For example, if an Exchange administrator sets Outlook to automatically deny all attempts to access address information using the Outlook object model, then Outlook will not allow the previous code example to access the To property, even though the code example uses the trusted ThisApplication object.

Specifying Which Add-ins to Trust When Using Exchange

When Outlook is used with Exchange, administrators can specify that certain add-ins can run without encountering the object model guard. Outlook add-ins created using Visual Studio Tools for Office cannot be trusted individually; they can only be trusted as a group.

Outlook trusts an add-in based on a hash code of the entry point DLL of the add-in. All Outlook add-ins created using Visual Studio Tools for Office use the same entry point DLL, AddinLoader.dll. This means that if an administrator trusts any add-in created using Visual Studio Tools for Office to run without encountering the object model guard, then all other add-ins creating using Visual Studio Tools for Office are also trusted. For more information about trusting specific add-ins to run without encountering the object model guard, see "Customizing Outlook 2003 to Help Prevent Viruses" (http://go.microsoft.com/fwlink?LinkId=24545).

Permission Changes Do Not Take Effect Immediately

If the administrator adjusts permissions for a document or assembly, users must quit and then restart all Office applications, including Microsoft Office Outlook 2003, for those changes to be enforced.

Other applications that host Microsoft Office Excel 2003 or Microsoft Office Word 2003 can also prevent the new permissions from being enforced. Users should quit all applications that use Office, hosted or standalone, when security policies are changed.

Trust Center Settings in the 2007 Microsoft Office System Do Not Affect Add-ins or Document-Level Customizations

Users can prevent add-ins from loading by setting an option in the Trust Center. However, some Visual Studio Tools for Office solutions are not affected by these trust settings. The following types of solutions continue to load:

  • Application-level add-ins created by using VSTO 2005 SE.

  • Document-level customizations created by using VSTO 2005.

If the user prevents add-ins from loading by using the Trust Center, the following types of add-ins will not load:

  • Managed and unmanaged COM add-ins (including Outlook 2003 add-ins created by using VSTO 2005).

  • Managed and unmanaged smart tags.

  • Managed and unmanaged smart documents.

  • Managed and unmanaged Automation add-ins.

  • Managed and unmanaged real-time data components.

The following procedures describe how users can use the Trust Center to restrict add-ins from loading in the 2007 Microsoft Office system. These procedures do not affect add-ins created by using VSTO 2005 SE or customizations created by using VSTO 2005.

To disable add-ins in Excel 2007, PowerPoint 2007, or Word 2007

  1. Click the Microsoft Office Button.

  2. Click the <ApplicationName> Options button.

  3. In the categories pane, click Trust Center.

  4. In the details pane, click Trust Center Settings.

  5. In the categories pane, click Add-ins.

  6. In the details pane, select Require Application Add-ins to be Signed by Trusted Publisher or Disable all Application Add-ins.

To disable add-ins in InfoPath 2007, Outlook 2007, or Visio 2007

  1. On the Tools menu, click Trust Center.

  2. In the categories pane, click Macro Security.

  3. In the details pane, select No Warnings and Disable All Macros or Warnings for signed macros; all unsigned macros are disabled.

  4. In the categories pane, click Add-ins.

  5. In the details pane, select Apply macro security settings to installed add-ins.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft