The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Microsoft Internet Explorer User Interface Race Condition
------------------------------------------------------------------------
SUMMARY
Microsoft Internet Explorer suffers from a potential user interaction race
condition 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.
A malicious web site, with a minimum of social engineering, may be able to
compromise user systems.
DETAILS
Vulnerable Systems:
* 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:
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.
Workaround:
* 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.
Vendor Response:
* Microsoft was informed of this vulnerability on October 20, 2005.
* As part of its December patch cycle, Microsoft issued the incomplete
<http://www.securiteam.com/windowsntfocus/6E00B15EUG.html> MS05-054 patch
which plugged a specific instance of this issue that had been previously
reported by Secunia.
* <http://www.securiteam.com/windowsntfocus/6E00B15EUG.html> 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
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2289>
CVE-2005-2289 (the File Download vulnerability patched by
<http://www.securiteam.com/windowsntfocus/6E00B15EUG.html> 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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:mattmurphy@kc.rr.com>
Matthew Murphy.
The original article can be found at:
<http://student.missouristate.edu/m/matthew007/advisories.asp?adv=2006-02>
http://student.missouristate.edu/m/matthew007/advisories.asp?adv=2006-02
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
