[Full-disclosure] 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:
http://student.missouristate.edu/m/matthew007/advisories.asp?adv=2006-02
(delayed)
Author: Matthew Murphy ([email protected])

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

• 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
http://securitytracker.com/id?1015720

OSVDB ID#22351
http://www.osvdb.org/displayvuln.php?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:

http://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs/

VIII. CONTACT

You may contact the author of this advisory via e-mail at
[email protected].

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38

iD8DBQFET++Pfp4vUrVETTgRA8UHAJ48EwHO0QojXk9SF/O9byAW978uXACgopfx
HrdJmlblNk9Z1GglitxtvYg=
=pzQx
-----END PGP SIGNATURE-----