A minor revision to the Word Vulnerability advisory

Hi everyone. It’s Stephen Toulouse again. We’re of course still hard at work on an update for the Word vulnerability. All indications still point to this being a very limited, targeted attack but we’re still spending a lot of time thinking about how customers can protect themselves from this vulnerability. Today we’ve made a couple of minor changes to the advisory we posted on this issue to provide more clarity on the workarounds. Here’s the link to the advisory:

http://www.microsoft.com/technet/security/advisory/919637.mspx

But let’s talk more about what can be done in general to help be protected from attacks that are similar to this. We’ve seen some security researchers post write ups around using a Software Restriction Policy to run instances of winword.exe in ‘Basic User’ mode. This does serve to block all the malware we’ve seen using this vulnerability so far. It’s more of a mitigation rather than a workaround, which prevents the exploitable condition.

What we’ve seen in general with these types of attacks is that the “Basic User” Software Restriction Policy is a “good practice” kind of mitigation that can prevent this specific malware from being successful. Michael Howard wrote about the “Basic User” SRP in his Writing Secure Code column. The reason it works in this case is because the malware attempts to install a kernel-mode rootkit and the “Basic User” mitigation does not allow this to happen. It’s key to note however that an attacker could find a way to bypass this mitigation but we haven’t seen that yet.

So if you’re looking for a more general way to add another layer to help protect against attacks like these, the SRP mitigation can work for many different types of Malware. We have a knowledge Base article that details the use of SRP’s here:

http://support.microsoft.com/kb/324036/en-us

Michael Howard detailed steps to do this with a variety of apps at this location:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01182005.asp?frame=true

And more information is provided here:

http://msdn.microsoft.com/security/securecode/columns/default.aspx?pull=/library/en-us/dncode/html/secure01182005.asp

Again, this is not meant to be a cure-all (or as Michael himself says, a panacea), but it’s interesting information we found in our investigations that can serve as a useful mitigation.

S.

*This posting is provided “AS IS” with no warranties, and confers no rights.*