On March 1, Microsoft released a security advisory related to Internet Explorer. Pressing F1 while using the browser could trigger a VBScript vulnerability allowing an attacker to take over your PC.
As of the first of March, Microsoft had released a security advisory related to the use of the F1 key while using its Internet Explorer browser.
With any luck, millions of Microsoft Windows computers should get a patch this Patch Tuesday for a VBScript vulnerability that could allow a remote attacker to take over the computer. So far, it seems that there are no exploits in the wild, as noted in Microsoft's security advisory:
Microsoft is investigating new public reports of a vulnerability in VBScript that is exposed on supported versions of Microsoft Windows 2000, Windows XP, and Windows Server 2003 through the use of Internet Explorer. Our investigation has shown that the vulnerability cannot be exploited on Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008. The main impact of the vulnerability is remote code execution. We are not aware of attacks that try to use the reported vulnerabilities or of customer impact at this time.
Microsoft says that the nature of the vulnerability is tied to "the way VBScript interacts with Windows Help Files when using Internet Explorer." Unless and until that vulnerability gets patched, the workaround to protect yourself is simply to avoid using the F1 key:
If a malicious Web site displayed a specially crafted dialog box and a user pressed the F1 key, arbitrary code could be executed in the security context of the currently logged-on user.
TechRepublic contributing writer Sterling Camden's take on the issue offers vivid illustration of the problem:
I can imagine Grandma sitting in front of a page that says, "Your computer's LHC has encountered fatal hard drive saturation. Press F1 for more information."
Microsoft identifies the following as affected software:
- Microsoft Windows 2000 Service Pack 4
- Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2
- Windows Server 2003 Service Pack 2, Windows Server 2003 with SP2 for Itanium-based Systems, and Windows Server 2003 x64 Edition Service Pack 2
A very vague reassurance is offered for MS Windows Server 2003 users as well:
On systems running Windows Server 2003, Internet Explorer Enhanced Security Configuration is enabled by default, which helps to mitigate against this issue.
Further information is available at the CVE advisory page for this vulnerability:
VBScript in Microsoft Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP2, when Internet Explorer is used, allows user-assisted remote attackers to execute arbitrary code by referencing a (1) local pathname, (2) UNC share pathname, or (3) WebDAV server with a crafted .hlp file in the fourth argument (aka helpfile argument) to the MsgBox function, leading to code execution involving winhlp32.exe when the F1 key is pressed.
Remedial vulnerability handling
It should come as no surprise that Microsoft continues to stick to its "responsible disclosure" guns on this matter. It has not failed to use its security advisory as a platform for trying to chastise security researchers:
Microsoft is concerned that this new report of a vulnerability was not responsibly disclosed, potentially putting computer users at risk. We continue to encourage responsible disclosure of vulnerabilities. We believe the commonly accepted practice of reporting vulnerabilities directly to a vendor serves everyone's best interests. This practice helps to ensure that customers receive comprehensive, high-quality updates for security vulnerabilities without exposure to malicious attackers while the update is being developed.
While this may seem perfectly reasonable at first glance, it is easy to read between the lines and see what Microsoft really wants from security researchers -- silence. As pointed out in "How should we handle security notifications? " there is a strong argument for sharing as much information as possible with end users whenever a new vulnerability is discovered, so that they may employ workarounds to ensure they do not suffer the ill effects of using vulnerable software in an unsafe manner. Microsoft's track record is one of attempting to punish any security researchers who do so, preferring researchers to inform nobody outside of Microsoft itself, then sit down and shut up.
By browsing through security advisory archives for researchers who abide by "responsible disclosure" as defined by corporations like Microsoft, one gets a pretty clear view of the end result of such a policy. Archives such as those of eEye Digital Security show that when nobody outside of such a security researcher and Microsoft employees know anything about a given vulnerability, it is all too common that the vulnerability may go eighteen months or longer without getting patched. The most common lengths for the period between an eEye report date and a Microsoft patch date is more than 100 days -- about three and a half months or more.
As of this writing, in fact, the most recent eEye vulnerability discovery was a remote code execution issue rated as High severity, and it took Microsoft 107 days to get around to fixing it after being notified by eEye Digital Security. To many security professionals, this kind of casual delay is regarded as an almost criminal shirking of responsibility for software security.
In the long run, the application of market forces as encouragement for Microsoft to change its ways, or for some competitor with a more conscientious approach to dealing with security vulnerabilities, is really the only way to solve the problem of such laxity. For all its talk about improving security policies, procedures, and design in recent years, Microsoft clearly has a long way to go before it can actually be regarded as a good example of a software vendor that handles security in a competent and ethical manner. It is only when its customers actually know about a vulnerability that the corporate software giant -- like most other large software vendors -- can be moved to swift action.
In the short term, however, we have been granted a piece of helpful information about the vulnerability of MS Windows via Internet Explorer, and should make use of it. The smallest adjustment to normal IE use to protect yourself would involve simply refusing to press the F1 button while using that Web browser. A more significant (and potentially more effective) adjustment for many would be to simply avoid using Internet Explorer at all, and choose some other browser in its stead.
For those of you using another operating system entirely, or a sufficiently new release version of MS Windows, this security advisory is probably not relevant.