You know the adage: When it rains it pours. On the heals of last week's 0-day Excel vulnerability comes two more Microsoft-related vulnerabilities, one in Excel and one in Windows.
A person using the alias "kcope" posted Perl code to the Full Disclosure mailing list that can generate a malicious Excel document. Other mailing list members reviewed the code and revealed that the exploit takes advantage of a stack overflow condition. While intial reports suggested that the problem resides within Excel, Microsoft clarified that the problem actually resides in the hlink.dll library. The library is a Windows component that handles hyperlinks and therefore the vulnerability might affect other applications in addition to Excel.
In order for a successful exploit to occur a person would need to click on a malicious hyperlink embedded into an Excel document. At the time of this writing no active exploits were circulating in the wild. Microsoft is still investigating the matter to determine the best course of action.
Another member of the Full Disclosure mailing list posted a different vulnerability that also involves Excel. According to the available details a malicious Shockwave Flash file object can be inserted into an Excel document and made to run automatically when the document is opened.
The discoverer began coordinating with Microsoft on the problem in early May. The company suggested setting the kill bit for Flash files so that an exploit would not be successful. Microsoft's article, "How to stop an ActiveX control from running in Internet Explorer," describes the process of setting kill bits and the settings are honored by Office XP and Office 2003.
Microsoft requested that the discoverer not publish an advisory about the vulnerability until at least June 20. Perhaps not so coincidentally, this month Microsoft published a security update for Internet Explorer that changes the way ActiveX controls behave. Instead of ActiveX controls automatically launching a user must click on a control before it will activate. Microsoft originally released a software update that made this change to ActiveX control behavior in February, but then released another update in April that rolled back the original update. The rollback was intended to give corporate customers more time to adapt to the eventual changes, which now become permament upon installing the most recent Cumulative Security Update for Internet Explorer released in June.