written by Tim.Rice
IBM recently released a fixlet that installs the Microsoft FixIt associated with KB2953095 to implement a Workaround for a flaw in how Word processes the RTF document types.
Microsoft Security Advisory 2953095
In our testing so far, it looks like the Fixit is installing itself under the System Account hive in the Registry, HKLM\HKEY_USERS\S-1-5-18 (because BESClient runs under that context).
Shouldn’t the fixlet have been using the RunAsCurrentUser to install the FixIt?
written by jgstew
It really seems like the fix should be system wide, not per-user. Some of the blame is on Microsoft if it is a per-user fix.
Have you tested this to see if it actually takes effect?
written by Tim.Rice
Yes, I deployed it to my desktop, rebooted, then logged back in and I’m still able to preview an RTF file I emailed myself.
I’m just now starting to look at what I need to change in the IBM provided task.
written by jgstew
From opening the MSI in ORCA, the MS Fix effects 2003, 2007, and 2010 (Both x32 and x64 versions of 2010)
What it really does is write the following to the registry:
ADDKEY1 1 Software\Microsoft\Office\11.0\Word\Security\FileOpenBlock RtfFiles #1 C_ADDKEY1
ADDKEY2 1 Software\Policies\Microsoft\Office\12.0\Word\Security\FileOpenBlock RtfFiles #1 C_ADDKEY2
ADDKEY3 1 Software\Microsoft\Office\14.0\Word\Security\FileBlock RtfFiles #2 C_ADDKEY3
ADDKEY4 1 Software\Microsoft\Office\14.0\Word\Security\FileBlock OpenInProtectedView #0 C_ADDKEY4
ADDKEY5 1 Software\Microsoft\Office\15.0\Word\Security\FileBlock RtfFiles #2 C_ADDKEY5
ADDKEY6 1 Software\Microsoft\Office\15.0\Word\Security\FileBlock OpenInProtectedView #0 C_ADDKEY6
K64_ADDKEY1 1 Software\Microsoft\Office\11.0\Word\Security\FileOpenBlock RtfFiles #1 C_K64_ADDKEY1
K64_ADDKEY2 1 Software\Policies\Microsoft\Office\12.0\Word\Security\FileOpenBlock RtfFiles #1 C_K64_ADDKEY2
K64_ADDKEY3 1 Software\Microsoft\Office\14.0\Word\Security\FileBlock RtfFiles #2 C_K64_ADDKEY3
K64_ADDKEY4 1 Software\Microsoft\Office\14.0\Word\Security\FileBlock OpenInProtectedView #0 C_K64_ADDKEY4
K64_ADDKEY5 1 Software\Microsoft\Office\15.0\Word\Security\FileBlock RtfFiles #2 C_K64_ADDKEY5
K64_ADDKEY6 1 Software\Microsoft\Office\15.0\Word\Security\FileBlock OpenInProtectedView #0 C_K64_ADDKEY6
See the attached screenshot for more clarity on the above.
I’m guessing this could be implemented using a combo of regset and regset64, and it could be done in a way that is more specific to the version of MS office installed. I’m fairly certain that these settings would take effect system wide if written to HKLM instead of HKCU, but not 100% sure.
written by Tim.Rice
I just verified that on my computer, the FileBlock keys are listed under HKey_Users\S-1-5-18\Software\Microsoft\Office\14.0\Word\Security\FileBlock
I’ve tried very hard to stay away from the CurrentUser concept in Fixlets so far. Time to break out the documentation and see what I can do, unless someone can convince the group at IBM that wrote the original task to adjust it to account for the placement of the keys.
written by jgstew
I don’t recommend running this fix as current user since it will only fix it for that user, and will not fix it globally. Then disabling the workaround later also becomes complicated, though perhaps not needed.
It would be better to write a BigFix native fixlet that fixes the issue system wide using regset
written by jgstew
I’m testing this in MS Office 2010
Key:
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\FileBlock
Value:
OpenInProtectedView
Options:
0 - do not open selected file types
1 - Open selected file types in Protected View (seems to be the default?)
2 - Open selected file types in Protected View and allow editing ( little to no protection )
Value:
RtfFiles
Options:
Nothing-ValueDNE - no protection for RTF files (default)
1 - prevent word from saving RTF files ( no protection )
2 - open RTF files using the security setting as defined in the “OpenInProtectedView” value above.
This is what is going on, but I need to test this in HKLM to see if it has an effect.
These settings can be manipulated by hand be opening word, then going to file menu, then options, then Trust Center, then Trust Center Settings, then File Block Settings.
written by Tim.Rice
If importing the keys to HKLM works, that would be great!
I was working off the assumption (!?!) that if the FixIt put the settings under the HKUSER key, then that was where the settings needed to live. Since a FixIt is “usually” executed by a user by clicking on a link in a WebBrowser, I assumed the Current User was the “Microsoft Preferred” location for the settings.
written by jgstew
I tested setting these values in the same locations under HKLM instead of HKCU and they seemed to have no effect.
These settings can probably be set using a GPO which would probably be the best option. It may even be possible to deploy it as a local GPO using BigFix, but I don’t have much experience with this option. If anyone has examples, it would be helpful.
The Office 2010 GPO templates are available here:
http://www.microsoft.com/en-us/download/details.aspx?id=18968
written by Tim.Rice
Thanks for checking.
I’m still going to pursue trying to create a version that will install the MS FixIt as the CurrentUser, mostly so I know how to make it work.
NOTE:
I’m not sure who wrote the original 2953095 Fixlet, but someone might want to talk to them about the impact of directly referencing HKEY_CURRENT_USER… registry items in Relevance clauses! I wonder how many people deployed that Fixlet thinking they were protecting themselves, when in fact they do not seem to be.
written by Tim.Rice
To add to the fun, when I tried to deploy the “Disable Workaround” fixlet, I get a SHA1 mismatch error on the download!
written by jgstew
Here is a good example of how to install using runascurrentuser:
http://bigfix.me/fixlet/details/2609
Adding the setting to block RTFfiles does work when added to the local group policy, but I’m not sure how to add local group policy through the command line or BigFix.
The local group policy gets added here: C:\Windows\System32\GroupPolicy\User\Registry.pol
And the effect of the policy is the proper keys get added to all users registries.
written by jgstew
It does seem like it should be possible to define a local group policy, then deploy it using the utilities found here:
written by jgstew
This does work, I should be able to create a task that does this with these utilities.
Apply_LGPO_Delta.exe
User
software\policies\microsoft\office\14.0\word\security\fileblock
RtfFiles
DWORD:3
written by jgstew
Here is a fixlet that does work to disable these settings using Local Group Policy, but the relevance may not properly report success/failure based upon the changes it is trying to detect.
written by jgstew
IBM has updated the fix to run as current user, so it will work now, but only for the currently logged on user. You would need to deploy it as a policy for it to work against multi user systems.
I still hope to have something that uses local GPO instead, as that does work for all users.
written by jgstew
What version of MS Office are you testing this fix against?
It seems like it blocks RTF files from opening in Office v11 & v12, but it sets RTF files to open in Protected View on Office 14+
Are your RTF Files opening in protected view?
written by jgstew
It also seems that the MS provided fix does not block RTFs that are “owned” by the current user, but will block RTFs downloaded from the internet / not “owned”
It could be that the inconsistency of the blocking is the cause of the confusion, or it could be that the fix does not work at all when deployed through IEM, not sure which is the case at this point.