Thread-topic: [VulnWatch] Internet Explorer User Interface Races, Redeux
> -----Original Message-----
> From: Matthew Murphy [mailto:mattmurphy@xxxxxxxxx]
> Sent: Thursday, April 27, 2006 2:09 AM
> To: undisclosed-recipients
> Subject: [VulnWatch] Internet Explorer User Interface Races, Redeux
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> Microsoft Internet Explorer User Interface Race Condition
>
> I. SYNOPSIS
>
> Affected Systems:
> * Windows 98
> * Windows 98 Second Edition
> * Windows Millennium Edition
> * Windows 2000
> * Windows XP
> * Windows Server 2003
>
> Risk: Medium
> Impact: Remote code execution (some interaction required)
> Status: Uncoordinated release
> Date Reported: October 20, 2005
> Date Released: April 26, 2006
> URL:
>
> dv=2006-02
> (delayed)
> Author: Matthew Murphy (mattmurphy@xxxxxxxxx)
>
> II. EXECUTIVE SUMMARY
>
> VULNERABILITY OVERVIEW
>
> Microsoft Internet Explorer suffers from a potential user interaction
> race in its handling of security dialogs. As a result, it may be
> possible for a malicious web site to install software on a visiting
> system or take other actions that may compromise the privacy or the
> security of the visitor.
>
> IMPACT
>
> A malicious web site, with a minimum of social engineering, may be
> able to compromise user systems.
>
> III. TECHNICAL DESCRIPTION
>
> 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:
>
> Enable
> Disable
> Prompt
>
> 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.
>
> IV. SUGGESTED ACTIONS
>
> WORKAROUNDS
>
> * 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.
>
> MITIGATION RECOMMENDATIONS
>
> * 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.
>
> V. VENDOR RESPONSE
>
> * 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.
>
> VI. REFERENCES
>
> SecurityTracker Alert ID#1015720
>
>
> OSVDB ID#22351
>
>
> NOTE: If other VDBs could indicate what identifiers they have assigned
> to this issue, that would be appreciated. I will use such IDs for
> reference points in the online version of this advisory to appear soon
> after the release of this version.
>
> VII. CREDIT
>
> Jesse Ruderman reported similar attacks against Mozilla Firefox, and
> provided the first research (that I am aware of) into user interface
> bugs and security ramifications of them:
>
>
> ty-dialogs/
>
> VIII. CONTACT
>
> You may contact the author of this advisory via e-mail at
> mattmurphy@xxxxxxxxxx
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment:
>
> iD8DBQFET++Pfp4vUrVETTgRA8UHAJ48EwHO0QojXk9SF/O9byAW978uXACgopfx
> HrdJmlblNk9Z1GglitxtvYg=
> =pzQx
> -----END PGP SIGNATURE-----
>
