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.