The information has been provided by Matthew Murphy.
The original article can be found at: http://student.missouristate.edu/m/matthew007/advisories.asp?adv=2006-02
* Windows 98
* Windows 98 Second Edition
* Windows Millennium Edition
* Windows 2000
* Windows XP
* Windows Server 2003
Microsoft Internet Explorer has an extremely sophisticated security model based on content "zones", which controls the behavior of web sites and how potentially unsafe content on them is handled. The browser reacts differently to potential security risks depending upon what "zone" the content originates in.
The zone-based security model has had some serious security breaches, many of which can be attributed to the previous use of the "Local Machine Zone" to provide application-level functionality to web content.
Most security settings in Internet Explorer allow one of three settings for each zone:
Starting with Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1, some prompting is now done via the "Information Bar" feature. Prior to these releases, most prompting is done via modal dialogs.
Those dialogs that remain are vulnerable to an exploitable timing condition that may result in unintended "Yes", "Allow" or "Install" answer to a security prompt. This situation is particularly serious on Windows Server 2003 RTM, Windows XP Service Pack 1, Windows 2000, and other older OSes, because prompting to allow ActiveX installation is still done via a modal dialog on those systems. On these systems, successful exploitation of this condition allows software installation as the logged on user.
On newer systems, the impact of this vulnerability is more limited, but remains serious. Many prompts continue to be delivered via modal dialogs. The most significant concern is that the default setting is "Enable" in most of these cases, meaning that users could potentially see their privacy compromised even if defaults had been significantly tightened.
A malicious user could create content that would request the user to click an object or press a sequence of keys. By delivering a security prompt during this process, the site could subvert the prompting and obtain permission for actions that were not necessarily authorized.
* Set security settings to "Enable" or "Disable" rather than "Prompt"
The vulnerability at issue depends fundamentally on a weakness in the browser's method of prompting when warning users of potentially unsafe active content on a web page. By preemptively disabling certain functionality that would otherwise generate warnings, the exploitation of this vulnerability can be prevented or mitigated.
This functionality can be accessed from the "Tools" menu's "Internet Options" button. The "Security" tab of the dialog controls all of these settings. Such security configuration can also be enforced via Group Policy.
IMPACT OF WORKAROUND: Disabling functionality where prompts would otherwise have occurred may limit the functionality of certain web pages that depend on potentially-dangerous active content such as ActiveX controls.
* Limit viewing to trusted web sites
In some situations, browsing can be successfully limited to only trustworthy sites without significant loss of productivity. Users should be extremely cautious while browsing unknown or untrusted web
sites, as such web sites are often able to introduce hostile code.
* Run exposed applications with reduced privileges
Users who log on interactively without the privileges of powerful groups such as the "Administrators" or "Power Users" groups are at a much lower risk of damage from successful exploitation of software vulnerabilities in client applications. This mitigation step greatly reduces the likelihood of a successful malware installation if this vulnerability is exploited.
* Microsoft was informed of this vulnerability on October 20, 2005.
* As part of its December patch cycle, Microsoft issued the incomplete MS05-054 patch which plugged a specific instance of this issue that had been previously reported by Secunia.
* MS05-054 does indeed provide minimal protection against subversion of the download prompting feature, but makes no attempt to secure other potential risk points.
* Contact with some members of the MSRC continued from the October report beyond this point, but contact from the assigned investigator did not take place until February 15, 2006.
* At that point in time, I was told that the vulnerability had been classed as a "Service Pack" fix, meaning that users of Windows 2000 will not receive a fix for this vulnerability.
* Further, the MSRC disputed my assessment that the vulnerability was at all similar to CVE-2005-2289 (the File Download vulnerability patched by MS05-054).
* Shortly after that decision, I informed MSRC that its assessment was incorrect and also that I had tentatively planned to disclose on April 24.
* MSRC could not provide me with a compelling justification for its choice of release timeframe. In a rather threatening e-mail, I was finally asked for exploit code, as well as justification of "why this issue is so important".
* After about an hour of work to actually write it, I provided the code to MSRC two days later on March 24.
* There is no further contact from MSRC following this point.
MSRC, for its troubles, got a two day reprieve because I was not yet prepared to disclose. So, I've (coincidentally) disclosed this issue in keeping with Michal Zalewski's informal "Bug Wednesday and Patch Saturday" policy. My experience with MSRC shows that Zalewski's strong objections to the generally-adversarial nature of the MSRC process and its lack of constructive results (particularly when Internet Explorer is involved) are well-founded. Simply put, don't shoot the messenger when your vendor and its patch processes are the problem most in need of a solution.