Hello, my name is Vikas and I work in the Office Trustworthy Computing security team. Today I will be telling you more about a feature I have been working on called Protected View. Protected View is one of the new security defense-in-depth features added in Office 2010. If you have not seen Brad’s post yet on this and the other new security improvements, it’s definitely worth taking a few minutes to look it over.
With any piece of complex software, over time new file parsing exploits against it may be found. The older Office binary file formats had been susceptible to these types of attacks. Over the past years hackers have discovered ways to manipulate Office binary files so that when they are opened and parsed, they cause their own code embedded within the file to run. To address these binary file parsing attacks in Office 2007, several new XML based file formats were introduced. These XML file formats are much easier to parse and provide a significant security benefit over the older binary formats. We do understand that there are still several billion binary files being used today and migrating to the new XML formats will take some time but if possible, the sooner you can migrate over, the sooner you can start leveraging the security benefits these new formats provide.
To address these attacks in the past, the Office team had released the MOICE (Microsoft Office Isolated Converter Environment). MOICE would take a potentially risky binary file type and convert it within a sandboxed process to the new XML format and then back to the binary format and open it. The hope of doing this conversion was to remove any exploit code that was hidden away within the file. Some downsides to MOICE were files that required a long time to convert would seem to take a long time to open and users would get frustrated. In addition, the conversion process did not always maintain 100% of the documents layout so there certainly was room to improve when it came to the overall user experience of the feature.
In Office 2010 when a file appears to be from a potentially risky location, such as the Internet, it is now opened in Protected View. Protected View will appear like any other read-only view. Under the covers however, when a file is opened in Protected View, it is being opened in the new Office 2010 sandbox. The Office 2010 sandbox is the “next version” of the MOICE sandbox described earlier. Unlike with MOICE, no file conversation is happening. In fact what is occurring is the file is being opened within a sandboxed instance of the application (Word, Excel, PowerPoint) and if there was malicious code present in the file the goal is that code would not be able to find a way to tamper with your documents; change your profile or other user settings. I will describe this in more detail a bit later in this post.
Since Protected View is a read only view, we understand it is not something that should be used for every file you interact with. Our goal when designing this feature was to only use it in high risk scenarios:
· Files opened from the Internet. When a file is downloaded from the Internet the Windows Attachment Execution Service places a marker in the file’s alternate data stream to indicate it came from the Internet zone. When a Word, Excel or PowerPoint file is opened and has this marker it will open in Protected View until the user decides to trust and edit it. That is done by pressing the “Enable Editing” button shown below:
In some cases when a file is opened from a network share that you believe is part of your Intranet zone it will open in Protected View and indicate on the trust bar that it originated from an Internet location. This could occur because of how your proxy is setup or because you have not indicated in your Internet Options – Local intranet setting to “automatically detect intranet network” as shown below:
· Attachments opened from Outlook 2010. When an attachment is opened from Outlook 2010 it will open in Protected View. Administrators will be able to configure if they want all attachments to open in Protected View or just those sent from senders outside their Exchange environment.
· Files opened from unsafe locations. An example of an unsafe location is files that are opened from your Temporary Internet Files folder. As an administrator you can extend this list to include directories you feel are also unsafe.
· Files that are blocked by File Block Policy. In Office 2007 we introduced a feature called File Block. This allowed administrators to define file types that should not be opened. When a type was blocked it simply could not be opened. From your feedback we heard that this was overly limiting from a usability aspect since your users still wanted to “read” those files. In Office 2010 these blocked files can now be opened in Protected View and as an administrator you can set policy to indicate if the user should be allowed to leave Protected View (by editing the file) or force them to stay in it. We hope this design will make all the issues and pains you felt go away!
· Office File Validation failures. Office File Validation is a new feature that scans an Office file when it is being opened and validates it against a well-known schema. When there are inconsistences between the file and the schema, the file will fail validation and will open in Protected View. Similar to File Block, policy will be available to determine if the user should be allowed to edit the file or not when a failure occurs.
· File Open Dialog. You can open files in Protected View explicitly by using the Open button:
The biggest gain is it lets us remove “are you sure” security prompts while giving you greater protection than you had in the past. For example, if you are an Outlook user like me you may have noticed that each time you open an attachment you are asked a question:
For me it is extremely hard to answer this question without seeing the contents of the file first. In Office 2010 we have removed this dialog and instead we now just open the file directly in Protected View! This allows you to look over the contents and make an informed decision if you really trust the file or not. If you do not, or if you only wanted to read it, you can get your job done and then close it. The reason we are comfortable opening the file directly is because of the many defense in depth checks we now have in place.
In addition to the open prompt, we also removed the Outlook Preview pane prompt shown below:
Now when you read Word, Excel, PowerPoint and Visio files in the Outlook preview pane you will no longer be prompted asking if you really trust the file first when Protected View is enabled.
Protected View had changed how Word, Excel and PowerPoint are architected. When a file is opened in Protected View there are two instances of the application that are running. To illustrate I will use Word. We have one instance of winword.exe that runs in the context of the account you are logged in as (we call this the “host” process) and we have another instance of winword.exe running in a very isolated process (we call this the “client” process). We also call the isolated process the Office sandbox and you will see these two terms intermixed.
The best way to describe it is with a picture. The client process is the part of the UI that is highlighted black and everything else is part of the host process as shown below:
When the user clicks on any part in the Host processes UI, because of UIPI, we have a high assurance the action came from the user and do not need to prompt with additional ‘are you sure you did this?’ dialogs. The host process owns the top level application frame window as shown above which includes the window caption, the ribbon, the trust bar, status bar, etc. The host process manages the Protected View and non-Protected View windows and acts as a “broker” for the client process. There is only one instance of the client/sandbox running at a given time and all files opened in Protected View share the same sandbox instance within an application. When all Protected View windows are closed the client process is terminated. When the client needs to perform a privileged task (such as accessing the file system, registry or other system resources) it makes a request to the host process and the host then will broker and perform the action if it deems appropriate.
As alluded to earlier, the client process is another Windows process that is running in the context of the user account however the token being used is a restricted token. By using a restricted token we were able to remove several rights and privileges this process has. To further lock down the client process we are also running it as a low integrity process. Together the restricted token and low integrity (UIPI) provide the foundations for our Office 2010 sandbox.
As discussed, Protected View is one of the many security defenses in Office 2010. For a malware to actually be able to run in Protected View it will first need to find a way around DEP, ASLR, GS and our new 2010 Office File validation checks. After all that, the malware would need to find a way to break out of the sandbox.
Hopefully now when you think you received a ‘scary’ Word, Excel or PowerPoint file you will be able to open it in Protected View and read it without having to worry that something bad could happen to your computer.
I appreciate you reading this far and stay tuned for more security posts coming soon!
Thanks.Vikas MalhotraSecurity Program ManagerOffice Trustworthy Computing
Thanks for this detailed explanation of Protected View and the office sandbox.
Glad to find that any file can be opened in Protected View through the Open ... drop down.
I've been playing with this and, in general, I really like the way it works. Avoids lots of issues we see with people opening attachments from emails, editing them and saving the changes back to the original message in Exchange, or worse losing their edits in a temp folder. However, the biggest frustration, in the Tech Preview, is not being able to Print when in Protected view.
Thank you for the details on how this works. In my environment (Win 7 RTM), *all* files on the Windows Server 2008 are detected as being from the Internet and opened in Protected View which is a significant productivity hit. I don't use a proxy and the Local intranet setting is already set to “automatically detect intranet network”. I've tried to work around this by telling Office to trust all network sources; this doesn't stop protected view. I've manually added the locations on the server to the Trust center - and I was infuriated that you don't let me add a root directory on a server so I have to add all the share mount points individually. And this is happening with .XLSX and .DOCX files which couldn't have code in to start with.
Protecting users from potentially malicious code in binary files is an excellent feature. What you currently have implemented is a productivity blocker that will be turned off or loathed by every user that comes across it. I hope the experiences of beta users will help you tune it from the latter to the former.
<<In some cases when a file is opened from a network share that you believe is part of your Intranet zone it will open in Protected View and indicate on the trust bar that it originated from an Internet location. This could occur because of how your proxy is setup or because you have not indicated in your Internet Options – Local intranet setting to “automatically detect intranet network” as shown below:
Sorry, but perhaps you could point to a URL that explains in simple terms
a. why a network share should be regarded as part of an Internet zone in the first place?
b. which parts of Office use file open APIs that regard network shares as part of the Internet, and which regard them as part of the Windows network file system?
c. precisely what security options people need to specify to make things accessible - on the file, the Windows share, so-called "IE options", etc.
At the moment, for some purposes, it's an incredible mess. We - the users - have to assume that someone at MS understands it all, but it isn't completely obvious that that is the case.
Just by way of example - and on a slightly different front, if I try to open a /Mailmerge data source/ from Word VBA using an HTTP:// URL, I can't. But if I specify the HTTP URL using the appropriate XML in a .docx or Word 2007 format .xml document, I can. Why?
Frankly, I think MS has lost the plot in this area and seems to assume that everyone in the world either has an advanced degree in MS networking, or should be able to rely on someone who has. How about spelling some simple stuff out?
I agree, not being able to Print is a bit frustrating but this is something we have been working on and will be there for Beta2.
How does the Protected View sandbox work on XP which does not have things like UIPI and low priviledge accounts? Are there any protections against malware infecting the machine?
We are working hard to incorporate user feedback to improve the product in Beta2 and are also looking for ways to improve the networking issue you mentioned. I really do not think that Protected View will be a productivity blocker. When a file is opened in Protected View and you click “Enable Editing” this will create a trust record for that file type and the next time you open the file it will not open in Protected View. If the file contains active content and you enable that content you will never be prompted to take that action again for that file. For this reason, I really think there is a productivity gain across the board in Office 2010 since we have greatly reduced the number of prompts users will see. Regarding the trust issue, have you added that UNC share (file://ServerName) to the list of intranet sites in Internet Explorer? You can do that by going to the Intranet options and selecting the advanced button which brings up a dialog that lets you add sites to the intranet zone. Once you do that the Office files should no longer open in Protected View for that server.
To determine if a file is part of the Internet Zone we call into the operating system API MapURLToZone (http://msdn.microsoft.com/en-us/library/ms537133(VS.85).aspx). An interesting article that explains this scenario can be found here: http://msdn.microsoft.com/en-us/library/bb250483(VS.85).aspx. I hope this helps better explain what is occurring under the covers.
On platforms that do not support UIPI, such as Windows XP, Protected View is not as robust as it is on the newer Operating Systems. That said, on XP Protected View is able to still leverage the benefits provided by the restricted token feature which does help prevent against attacks.
Vikas - can you explain the difference (if any) between using the Trust Center in Office/Options and using the IE intranet sites? How would it differ if I only have Firefox on my system? Will using the IE intranet setting not refuse to trust the server root, and if so do you plan to allow Trust Center to trust the server root?
Presumably it's a bug that I have to add the server in the first place, even though I don't use a proxy and had your suggested settings already enabled in the Internet control panel? Is it also a bug that I'm seeing it on .DOCX and .XLSX files that cannot contain macro code, or is it actually scanning all files, even XML format files that are supposed to not be able to contain code?
Is it possible to disable protected view? I didn't manage to find it over the internet.
gostava de ver o office 2010 na mini barra de funçoes.
Great. Now how do I turn it off. It's annoying having to press 'enable editing' on every document I open.
Honestly, it's enough to make me to move to Google Docs since they don't have this silly feature. The straw that broke the camel's back for my using IE (I'm mainly using Firefox now) was the silly nanny dialogs that come up when moving images from a website to my desktop. I took an action to move the file, why would I not want to allow it?
If a user were intent on editing the file, would there EVER be a case where a user does not select 'Edit'?
re: Protected View in Office 2010
I think it is good FETCHER in this kind of danger internet
Why is printing scary? I can see why editing might not be a good idea.
I think it is good.