A Look Back at KB2953095 Mitigation Option: Using Group Policy to Open RTFs in Protected View
Hi Folks,
Dan Cuomo, Microsoft Platforms PFE, here to discuss one of the mitigation options available for the recent KB2953095: “Vulnerability in Microsoft Word could allow remote code execution.”
If you subscribe to the technical security notifications you may have been relieved to read the advance notification that came out on April 3rd announcing the patch. Prior to the patch release (which was April 8th), many fellow IT Pros were scrambling as my phone bill will attest. I’ve been on calls with customers, calls with the customer reviewing that call, calls from other customers who asked what the aforementioned customers decided on their calls – But all of this rigmarole for a very good reason, this was a clear and present danger (sure I forced that…I’m no Jeff Stokes).
Now if you’re saying to yourself, “What’s the big deal, Dan? We approve all the security patches that come through WSUS so we should be good-to-go, right…? …right…?”
…wait for it….
During the long literary silence, you may have considered your timeline. After receiving the patch on the 8th, testing your lab, and finally applying it to the end user systems, Joe and Jane User (it’s a family business) may have been stuck with plain-text email for over a month.
Now take a stroll towards your help desk and ask if the call volume has been unusually high recently…
While plain-text email is certainly an inconvenience, it wasn’t considered a show-stopper for customers. It’s also only one of the mitigation methods. This specific vulnerability was identified as affecting RTFs in Word. This led many customers to consider using the “fix-it” (in the KB above) to disable the ability to open RTFs altogether. The big concern is that for many customers, disabling RTFs in this manner is out of the question, or at least for some users in the enterprise. It would help protect them, but ultimately break their LOB application.
If this was your situation, this article is for you. I won’t go into all of the mitigation techniques identified in the Security Advisory, or even discuss the intricacies of the vulnerability (for that, head over to Recommendation to Stay Protected and for Detection). What I will show you is how you can use our great friend ** insert trumpets here ** group policy to turn a difficult crisis into a simple, minimally invasive, and temporary solution. As always, remember test in your lab first!
** To be clear, you should always investigate and implement as many mitigation options as possible while balancing the functionality of your mission critical apps.
Force RTFs into Protected View Using Group Policy
First, download the Office ADMX Templates for the installed version of Office in your Enterprise (2010 or 2013). Double click on the download (admintemplates_64bit.exe in my case) and point the installer to a folder. The installer creates two folders and an excel spreadsheet.
Navigate into the ADMX folder. As you can see, the full list of Office ADMX files for each Office application is listed. There are also language specific folders containing ADML files. We’ll need the corresponding files for Word.
Note: You could easily copy all the files into the central store, or the ADMX files and a single language-specific folder. In this example, I’ll only include the files necessary for this mitigation. If you haven’t already created your central store and want a bit more information on taking the plunge, check out Tom Moser’s and Mark Morowczynski’s article .
Copy the files over to your central store
Open Group Policy Management and create a new policy, linking it to the user’s organizational unit that require the policy. Remember to name this appropriately and provide an accurate comment. This is not a long-term solution, so we’ll want to make sure that we can easily identify and remove the policy later.
Right-Click and edit the policy. As you can see, the administrative templates are now being pulled from the central store. The available policies are all located under User Configuration.
Navigate to Administrative Templates > Microsoft Word 2013 > Word Options > Security > Trust Center > File Block Settings
Enable the “RTF Files” Policy and Select “Open in Protected View.” As the description indicates, this setting will only allow the opening of the file in Protected View and will disable editing and saving of RTFs.
Log into a client machine with a user to which the policy applies and open any RTF file. As you can see, the document opens in Protected View.
When I attempt to edit the RTF, I receive the following message in the Status bar.
Clicking on the bar at the top “Protected View Editing this file type is not allowed due to your policy setings: Click for more details.” Brings me to the following:
Clicking on “File Block Settings” identifies the locked setting, denying access to open or save RTFs
Lastly, when we look at the registry we see the rtffiles dword added to the registry and set to 4.
Removal of the GPO
As we previously mentioned, this was a quick and temporary workaround until the patch arrived. Once that occurred and you verified that your systems have been updated, it’s time to remove the mitigation and enable RTF functionality for your users again.
You may have noticed that the registry key associated with this policy lives in one of the “preferred” group policy user settings locations; it is a “true policy.” This means that the key is fully managed and the system will return to its default behavior when the policy turns out of scope.
As a test, we can simply unlink the policy.
Log back into the client system and try opening your RTF again. I no longer see the “Protected View” message. I can edit and save the document.
The trust center confirms
And the registry keys are removed
Mixed Office Version Environments
The above will work, but unfortunately only for Office 2013. Do all of your systems have the same version of Office installed? Perhaps you’re in the middle of an upgrade or maybe you have another business justification. Whatever the reason, the simplest fix is to add the Office 2010 ADMX files to your central store.
You’ll notice that there are additional Policies for Office 2010
You can configure this in the exact same manner as with Office 2013.
I would recommend using separate policies for simplicity. I’m not going to venture into the arena of how to delimit the policies because ultimately, it depends. However if you’re considering a WMI filter make sure you’re aware of Ned’s warning on How to NOT Use Win32_Product in Group Policy Filtering
After logging back onto the client, Office 2010 also opens the RTF in Protected View
The “downside” of not filtering in some manner is that you’ll have processed the extra setting in that GPO for an application version you may not have installed.
Keep in mind that there are other mitigations to this vulnerability as identified in the advisory however the implementation of any of these must ultimately accommodate your business requirements.
On a separate note, testing has shown that Microsoft’s free tool EMET thwarts this exploit using its default configuration.
However, if you do not currently have EMET in your environment rolling it out in the middle of a crisis is not the time you want to start. You need to vet your business applications for compatibility and protect against this threat immediately. Until then, using group policy and the office ADMX templates in the central store allowed us to easily and quickly implement a minimally invasive mitigation technique.
Until next time,
Dan “I don’t always open RTFs but when I do, I open them in Protected View” Cuomo
List of References:
Security Advisory 2953095: recommendation to stay protected and for detections
Microsoft Security Bulletin Advance Notification for April 2014
Advance Notification Service for the April 2014 Security Bulletin Release