On February 24, 2009, Microsoft published Microsoft Security Advisory 968272 confirming the existence of a recently disclosed 0-day vulnerability in Microsoft Office Excel. For now, there are reports of only limited and targeted attacks attempting to exploit this vulnerability. Unfortunately, with public disclosure and exploits in limited circulation in the wild, the risk is high that more widespread attack will follow.

The flaw lies in code handling the Microsoft Office 2003 and earlier binary file formats. Microsoft confirmed that all versions of Office 2000 and later are at risk. The list of affected platforms also includes Mac OS X, with Microsoft Office 2004 for Mac and Microsoft Office 2008 for Mac being vulnerable.

Even in the absence of a security update from Microsoft, there are some good recommendations included in Microsoft’s advisory.

The Microsoft Office Isolated Conversion Environment (MOICE) offers users of Microsoft Office 2003 and Microsoft Office 2007 a way to more securely open Microsoft Word, Excel and PowerPoint binary format files. KB968272 contains details on how to set MOICE as the registered handler for .XLS, .XLT, and .XLA file formats. Documents that are converted to the Office 2007 XML format with MOICE will lose their macro functionality (which depending on your perspective might not be such a bad thing). Password protected or DRM encumbered documents can’t be converted with MOICE. Mac users are unfortunately left out in the cold here, since MOICE isn’t currently supported on the Mac OS X platform.

You can also block your users from opening Office 2003 and earlier documents using Microsoft Office File Block policy. KB968272 contains details for Microsoft Office 2003 and Microsoft Office 2007 on applying registry changes to prohibit users from opening Office 2003 format documents. Office 2007 offers the ability to manage “trusted locations” that can be excluded from the File Block policy. Office 2003 users must instead use an OICEExemptions registry key if they want to exempt a directory from the File Block policy.

It remains to be seen if OpenOffice or other alternative office suites are affected by the same kind of programming flaw that caused the vulnerability in Office. Although Microsoft’s new Office Open XML (OOXML) formats, and the SDLC-developed code that Microsoft wrote to implement them, do seem less at risk to these kind of vulnerabilities than the legacy formats, a move to the exchange of strictly OOXML would have its own drawbacks. Some older releases of Microsoft Office and many alternative office suites do not support the newer OOXML formats. Even users of Office 2003 must go out of their way to install additional software from Microsoft in order to open OOXML documents. When exchanging documents with partners in a business setting, the recipient’s ability to easily read the attachment is an certainly an important consideration.

The Microsoft Security Response Center is a good source for updated information as Microsoft’s investigation continues. I’m sure there will be new developments on this issue shortly.

References:

CVE-2009-0238

On December 9, 2008, a “weaponized” zero-day exploit for a previously undisclosed vulnerability in Microsoft Internet Explorer 7 was discovered in the wild being used by Chinese hackers to install malware on victims’ computers. The exploit was based on a proof-of-concept that was posted on a Chinese forum early in November of 2008, and coincidentally, launched on the same day as Microsoft’s last batch of security patches for the year. The vulnerability is caused by memory corruption that results from an invalid pointer reference when Internet Explorer handles Dynamic HTML (DHTML) data bindings. The exploit itself is written in JavaScript and is intended to execute only in Internet Explorer 7 browsers on Windows XP, Windows Server 2003, Windows Vista, and Windows 2008; however, the underlying vulnerability resides in all versions of Internet Explorer. As of this date, no exploit for them has been discovered.

To exploit this vulnerability, a malicious website would cause IE to create an array of data binding objects, release one of the objects and re-reference it later on. The result is that Internet Explorer neglects to check the new array length after the object is released and a loop will continue to reference the released object, resulting in a use after free condition. If the deleted object’s memory space is reallocated and filled with user supplied data, Internet Explorer could crash in a way that is exploitable and effectively allow for remote code execution with the privileges of the logged-in user. While most attacks that exploit this vulnerability are being used to propagate malware, one must realize that this vulnerability can be leveraged to execute arbitrary code.

There are inherent vulnerabilities that exist in all browsers, but Internet Explorer is the most widely used web browser around the world, making it a prime target for hackers. The time between the release of proof of concept code and the release of full-fledged exploits is getting smaller and smaller. Although Microsoft has been quick to release workarounds to mitigate vectors for exploitation, the seriousness of this flaw has prompted Microsoft to release an out-of-cycle security update, MS08-078.

In order to maintain a good security posture, minimize your risk by being aware of the vulnerabilities that may pose a threat, and be prepared to show due care when a threat comes knocking at your door. Considering that security and functionality can often be a tradeoff, there isn’t a single product or configuration that caters to everyone; the solution is to figure which tradeoffs are appropriate for you or your company. As such, until issues like this can be addressed with a security patch, users should apply the workarounds, and/or consider using an alternate browser in the meantime.