Welcome to MSDN Blogs Sign in | Join | Help

Microsoft Excel

The team blog for Microsoft Excel and Excel Services.
Trust Center Part 4: Trusted Locations

Today we have the fourth guest post from Sam Radakovitz, Excel Program Manager.  Sam is writing about the Trust Centre, a new feature for Office 2007.

While we have talked at length about reducing the impact of security decisions on end customers, and of having Office 2007 make secure default decisions, it’s important to note that the implications of those decisions is usually to disable code or some part of a solution because we don’t have sufficient information to trust it.

In the past one way to enable a solution was to digitally sign the code and once the user trusted the Publisher’s certificate the code was always enabled.  This is still the premier and preferred ‘evidence’ for a customer to make a trust decision on, and customers should insist that ISVs publishing code to extend Office sign that code.  Even individual end customers have the option of self-signed certificates for use with code on their own machine, which one can create using the “Digital Certificates for VBA Projects” tool shipping under the Microsoft Office Tools toolset.

However, for ad-hoc team and department level solutions getting code signed with a certificate valid for all customer’s machines can be a challenge.  This challenge has led some customers to change their default settings, which only allows signed code from Trusted Publishers to run without notification, to Medium or even Low security.  Low security allows all macros to run, including those from email attachments etc. and puts the user at significant risk.

Office 2007 addresses this risk by providing additional flexibility for the ad-hoc sharing scenario using the notion of Trusted Locations. A trusted location is a folder or document location, from which Excel will trust documents and allow them to open and run code without notification to the user.  Excel has always had a limited set of folders from which they would trust a document and allow it load and run code.  Office 2007 allows the user or administrator to add new locations. The following screenshot shows the management UI for Trust Locations in the Office 2007 Trust Center.


(Click to enlarge)

It’s important to note that creating a trusted location is a significant trust decision and should not be made lightly.  Particular care should be taken when remote locations are added to the Trusted Locations list as code from any document in such a location will be trusted and run without challenge by the Office application.  (IT Administrators have the ability through custom install and policy to restrict what locations are trusted on customers’ machines and what type of locations customers can add etc.) It’s important that any location trusted by the user is well managed with restricted access to only those who are authorized to publish documents and code to a user’s machine.

This flexibility – allowing the trusting of all documents in an arbitrary folder – may on first glance seem a risk. But the ability for an ad-hoc set of customers to create a specific trusted location for a solution they use regularly should actually result in an improved security stance because, as mentioned above, the common alternative is to reduce their settings such that all such code (including email attachments etc.) can run, which is much more dangerous.

To further mitigate the risk of ‘rogue’ Trusted Locations, Office 2007 does not allow remote (off the user’s machine) locations by default, and can revoke them all easily.  Additionally, Office 2007 explicitly blocks certain risky folders, like the Outlook cache for attachments, the Temp folder and others where documents are sometimes temporarily stored and will never trust them.

Finally, Office 2007 allows such “solution” focused documents to be trusted for more than just VBA macro code. These documents can update data from remote sources automatically, initialize ActiveX controls etc. and truly run as a solution, once trusted as such, without blocking the user with prompts.

Posted: Tuesday, August 01, 2006 7:41 AM by David Gainer

Comments

Harlan Grove said:

As long as %APPDATA%\Microsoft\Excel\XLSTART is a trusted location by default, who wouldn't target it? And it's the same for most users across companies and countries. It's a great big bullseye for maliciously constructed XLS files.

While signing and certificates may be a royal pain to handle in a distributed environment, keying on particular document properties, such as the original creator's name, would nicely complement trusted locations. Any file can have only one creator, so only one creator's name. And most companies and individuals across the globe are highly unlikely all to trust the same person(s).

Trusted locations without either signing and certificates or checking file creator's name is a bad joke. It makes these locations inherently insecure. MAYBE if trusted locations were restricted to network shares in which users can't save files, either new ones or modified existing ones, they'd be OK. That way IT departments or other central authorities could distribute files to trusted locations, but users couldn't. That'd handle XLA[M] add-ins and XLT[M] templates.

XLS[M] files with macros in which users would be expected to make changes would be trickier. Maybe the best that could be done would be putting all the VBA/macros/udfs into XLA[M] add-ins and none into the XLS[X] files. Have users load such models by loading the add-in, and put Open event handlers in the add-ins to prompt for the XLS[X] file to open.
# August 1, 2006 12:44 PM

Kevin Boske - Office Development said:

As developers writing code for Office, we all need to be aware of security. Let's face it, we've...
# August 1, 2006 3:30 PM

sam said:

"Any file can have only one creator, so only one creator's name. "

Harlan....some years ago... I lost a challange

The challange was to try and create a xls file which if you copy and open the copy will pop up a message..."You have a copy of the orginial"

I tried several approaches...one of them was to get the file creation date, time (minute, hour, sec)of the orginal and compare it with the copy....

Unfortunately if a user simply set the date of his computer to that of the original file and the time a few seconds(say 10) before the original file creation time... and started making copies....one of them will have a date and time of the original....trial and error...but will work...

It is sad that a file's creator doesnt change when copied.....In my opinion it should...It could be used as a one of the parameter to test if the file is an original or a copy

A problem with the the windows os..that we have to live with...


Sam
# August 2, 2006 12:27 AM

A User said:

Given that a certain amount of paranoia seems justified these days, this seems a reasonable approach even though it is somewhat inconvenient and is still susceptible to some attacks. Thanks to Dan, Sam, & Sam for workaround suggestions in the Part 2 thread.

I do have an issue with the "disable without notice" option. I realize this is only an option, and probably not a default one, but when a file is opened in a mode other than its intended mode of operation there really should be a warning. If someone has good reason to do this regularly they should be able to deal with a click through, and would probably benefit from visibility of the mode. If not, they should be warned away!
# August 2, 2006 4:00 PM

samrad said:

Hey again!  Thanks for the comments, replies below:

Harlan:
we wanted to ensure xlstart is trusted mainly for backwards compat.  since the locations are customizable and admin controllable, they can remove xlstart if they don't need it, and trust only particular locations, like only network shares as you suggest.  also note, there are other layers of security that will help against putting malicous files in there (os/ie wise).  just to state it again, particular care should be taken when designating a path as a trusted location.

A User:
You're right, the disable w/o notification is not the default :)  We wanted to make the settings flexable, and allow admins to configure when their users would see security issues and alerts.
# August 7, 2006 7:05 AM

Marco Scheel aka GeekDotNet said:

Wer mit SharePoint arbeitet und darin die üblichen verdächtigen Dateitypen der Office Familie verwendet, kennt vielleicht die Securityhinweise, wenn zum Beispiel Excel aus einer SharePoint Lib geladen wird. SharePoint gilt in solchen Situationen eigentlich

# June 6, 2009 4:13 PM
New Comments to this post are disabled
Page view tracker