Mitigating Newly-Reported Word Vulnerability

A new vulnerability has been uncovered in Microsoft Word that appears to permit the execution of arbitrary code when an unsuspecting victim opens a malicious Word document. The vulnerability is known to affect Office XP and Office 2003, but I would not rule out other versions being affected as well.

The vulnerability was first used in what appears to be a highly-targeted attack. As such, the number of compromises attributed to this vulnerability is low, and I’d expect that we’ll have at least a few days before that number climbs significantly. It is of note that the payloads of the known in-the-wild exploits require the user to be running Microsoft Word with the privileges of an administrative user. As such, organizations and individuals who follow best-practice and log on interactively as non-administrators are currently not at risk. Based on feedback, I should also note that you are at less risk from any exploit of this vulnerability if the vulnerable application is running without full privilege.

Windows XP users have a little-used weapon that they can use to blunt the effect of the in-the-wild malicious code targeting this vulnerability: software restriction policies. By using the “Basic User” SRP, users can launch Microsoft Word without the ability to write to certain registry and file system locations that the in-the-wild malware requires access to. This is a stop-gap measure based on the threat profile of the in-the-wild malware at this time and is only necessary if you’re still running interactively as an administrator. If you are, it should be a priority to change that if at all possible.

I’ve produced a simple registry script that sets a Software Restriction Policy that runs any instance of ‘winword.exe’ with the ‘Basic User’ policy. Once the registry script has been imported, the SRP can be rolled back (if desired) via the Security Policy snap-in.

The registry script is available here. It is PGP signed with my new (as of May 15th) RSA key. For reference, I have signed this new key with the (shorter, older) DSA key. However, the DSA key is deprecated and will be allowed to expire, due to the reliance of DSS on the weakened SHA-1 hash and the shorter lengths of DSA signing keys.

In addition to the standard disclaimer that you assume any and all risk associated with applying this change, I should also note that the effectiveness of this registry fix is entirely based on known characteristics of the payload, rather than the exploit itself. As such, it is possible that future variants of the in-the-wild exploits (which target the same underlying vulnerability) will eliminate the dependence on administrative privileges and thus, reduce the effectiveness of this workaround.

  • this_is_bullshit

    the content doesn’t match the title at all:
    title indicates it’s about word vuln;
    but content is totally about the trojan.


  • Dcrab

    WTF are you talking about? I can’t see any fucking mention of a trojan??

    Great post Matthew, always great reading your blog.

    – Dcrab

  • Matthew Murphy

    The existing exploits do drop a trojan horse as part of their payload. Fortunately, the successful installation of this malware requires Administrative privileges. Reducing the privileges of the vulnerable application thus completely eliminates the impact of the in-the-wild malware. Also of note is that if you are exploited by a more sophisticated piece of malware (one that doesn’t require administrative privileges to install), your system will be at a substantially reduced risk regardless, because the malware will only have those user rights instead of complete control.

  • jnf

    The exploit drops an executable that it runs, I’m not sure SRP would really help here, unless you don’t want word being able to write temporary files. Although, I suppose you might be able to prevent the execution of files in the temporary directories.

    This attack is ‘highly targeted’ in a manner of speaking, several thousand attacks have occured and started about a month ago, but the receipients have all been part of several organizations or you could look at it like as part of one much bigger organization.

    I’m not sure there will ever be much information on this out, at least not until a patch is released. It looks like the exploit touches a piece of functionality you can opt to turn off, but I haven’t verified this as of yet. Additionally, don’t be surprised if the bug actually affects all/most/other components of MS Office, the functionality exists in some of the other programs as well.

  • Pingback: IA Inside the Beltway

  • Pingback: my Journal » Blog Archive » The MS-Word Zero Day

  • Matthew Murphy


    The SRP is effective against the attack. The SRP reduces the privileges of Word to those of a Basic User. SRPs apply to all child processes the “restricted” app (Word) launches. That means that if Word is attacked, anything the compromised instance of Word can launch is restricted to at most Basic User permissions. Any SRP that applies to the launched application can further reduce its privileges or deny execution rights completely. If you want to validate this hypothesis, install my registry change and then add an SRP for “cmd.exe” to run “Unrestricted”. From the Open menu, find cmd.exe, right-click it, and choose Open. You’ll find that even though that SRP is “Unrestricted”, cmd.exe runs with the token of the process that created it (Word) and thus, its privilege limits. Cmd.exe instances run directly from the interactive desktop, on the other hand, will run with full privileges. Also of note is that Microsoft’s advisory seems to indicate that only Word is affected.

  • Pingback: 傻傻Kevins

  • Juha-Matti

    Matthew, your work was covered here:,1895,1966009,00.asp

  • Suzanne Auten

    Thanks for creating this fix as I do need it. I’ll be running it tonigh. But there is I don’t understand. When Microsoft comes up with a larger, permanent fix, how do I undo your fix?

  • Pingback: SecuriTeam Blogs » Microsoft fixes Word 0-day - related to Smart Tags