We’ve had several questions regarding some recent issues that have affected Microsoft Excel over the last week. So, I thought I’d take a minute to review each, what the security impact could be for each issue, and what we’re doing to resolve the issues.
We’re currently investigating three issues that have mentioned Microsoft Excel. The first one involves a vulnerability in Microsoft Excel itself. This issue has been assigned vulnerability identifier CVE-2006-3059. (The vulnerability identifiers are included within all of our security bulletins and security advisories and are a great way to help differentiate issues.) We released Security Advisory 921365 on Monday that has a full overview of this vulnerability, along with mitigations and workarounds. A couple key points - customers using Excel 2002 (included with Office XP) or Excel 2003 (included with Office 2003) will be warned before opening the attachment from an e-mail or a Web page, so remain careful when opening unsolicited files. Also, in the advisory there are instructions on how to modify the Access Control List (ACL) of a registry key that can block exploitation on Excel 2003. We’ve reached out to our partners in the MSRA and are sharing generic detection information for the vulnerability itself. The Office product team is currently testing updates that resolve the issue, and we expect to have it ready for release on or before July 11th.
Another issue was reported early this week that we discussed in the following post: http://blogs.technet.com/msrc/archive/2006/06/20/437826.aspx. This vulnerability has been assigned vulnerability identifier CVE-2006-3086. The vulnerability is in a Windows component, Hlink.dll, however it affects customers that open a specially crafted office document, and then click on a hyperlink within that document. Customers using Office XP or Office 2003 will get the same prompts as with CVE-2006-3059 when opening documents, so once again, being cautions when opening Office documents helps here as well. However, in our testing of the public posting we’ve seen that after the document is opened, for an attack to be successful, a user would still need to click on a link within that document and will be given a second prompt asking if the user does in fact intend on navigating to that destination. While the dialog doesn’t present a security-specific warning, the destination will include attack code, and does not look like a legitimate destination. So some social engineering would be required to make this attack successful. However, the fact that social engineering is required hasn’t stopped us from working quickly. We’re currently testing a fix for this issue and are investigating workarounds for customers.
The third was reported on Tuesday and that issue involves a method that allows an ActiveX control to be loaded within an Office document. The public posting on this has an example that involves an Excel document, so some folks may confuse this with the two issues above. This behavior is by design and by itself does not represent a security risk to customers. However, an attacker could use this functionality to automatically load a vulnerable ActiveX control already present on a user’s system through an Office document. It is important to note that this is not a vulnerability and recent versions of Office respect the “Killbit” functionality of Windows that prevents vulnerable ActiveX controls from loading once they have received a kill bit through a Microsoft Security Bulletin. We’re not aware of any vulnerable ActiveX controls that could allow remote code execution in this context or of attempts to use this method of attack or of customer impact at this time. We will continue to investigate the public reports to help provide additional guidance for customers as necessary.
--Mike
*This posting is provided “AS IS” with no warranties, and confers no rights.*