ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FW: [VulnWatch] Advisory: Internet Explorer Drag and Drop Redeux [CVE-2005-3240] (fwd)



> -----Original Message-----
> From: Matthew Murphy [mailto:mattmurphy@xxxxxxxxx] 
> Sent: Tuesday, February 14, 2006 3:47 AM
> To: full-disclosure@xxxxxxxxxxxxxxxxx; 
> bugtraq@xxxxxxxxxxxxxxxxx; vulnwatch@xxxxxxxxxxxxx; 
> bugs@xxxxxxxxxxxxxxxxxxx
> Subject: [VulnWatch] Advisory: Internet Explorer Drag and 
> Drop Redeux [CVE-2005-3240] (fwd)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> 
> My apologies to those who are receiving this late or are otherwise
> inconvenienced by the staggered release.  I had unexpected, 
> last-minute
> travel issues that interfered somewhat with today's release.
> 
> Of note since the initial drafting of the advisory is that 
> Microsoft has
> released a blog post on the MSRC blog about the vulnerability report,
> which can be read here:
> 
> http://blogs.technet.com/msrc/archive/2006/02/13/419439.aspx
> 
> The technical/strategic points about the exploit that are 
> raised in the
> post are indeed accurate (though it references MS05-014, when 
> I believe
> the correct reference is MS05-008/MS05-013).  The exploit has 
> a greater
> dependence on timing than previous, related attacks.  As such,
> Microsoft's decision not to include this issue in a 
> standalone patch is
> seemingly justified at this point.  However, the point of disagreement
> with Microsoft remains the choice of release *timeline*.
> 
> I released the information about this issue to a trusted 
> colleague (Gadi
> Evron) for publication today, after what I felt was a reasonable time,
> in light of my difficulties obtaining internet access.
> 
> Though there are disagreements between myself and Microsoft about the
> nature of this vulnerability, I would like to thank Brian 
> Schafer of the
> MSRC for adhering to a high level of professionalism and technical
> accuracy in that post and for continuing to work with me once it was
> made clear that the issue would imminently become public.
> 
> Also of note is that there was a typo in the information I provided
> originally to SecuriTeam.  The proper candidate is CVE-2005-3240, not
> *3840* as was originally reported by me.  SecurityFocus has also
> informed me that my original BID reservation was a casualty of a data
> migration and that the proper BID associated with this 
> vulnerability is
> now BID 16352, which is public in full detail as of this writing.
> 
> There have also been some incorrect reports made to 
> SecuriTeam that this
> issue does not affect Windows XP Service Pack 2.  These 
> reports are not
> correct -- my testing during this investigation was done 
> exclusively on
> current installations of Windows 2000 and Windows XP.  These 
> systems had
> all service packs applied and all updates installed when tests were
> performed.
> 
> Thanks to Gadi Evron for doing some of my bidding today and 
> taking some
> of the heat for my fat-fingers.
> 
> The final advisory, corrected with the now-accurate references is
> attached with an armored-format PGP signature inline.
> 
> - --
> "Social Darwinism: Try to make something idiot-proof,
> nature will provide you with a better idiot."
> 
>                                 -- Michael Holstein
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38
> 
> iD8DBQFD8Shufp4vUrVETTgRA/hpAJ9DobMIa4EH8otBMNlzIPK6RrMGUgCfcrrj
> ZI9G00rer59rLkwI5uH0KGQ=
> =DQ2a
> -----END PGP SIGNATURE-----
> 
Microsoft Internet Explorer Drag-and-Drop Redeux

I. SYNOPSIS

Affected Systems:
        * Microsoft Internet Explorer 5.01
        * Microsoft Internet Explorer 5.5
        * Microsoft Internet Explorer 6.0
                - Windows 98
                - Windows 98 Second Edition
                - Windows Millennium Edition
                - Windows 2000
                - Windows XP
                - Windows Server 2003

Risk: Medium
Impact: Potential remote code execution with some user interaction
Status: Uncoordinated Release
Author: Matthew Murphy (mattmurphy@xxxxxxxxx)

II. VULNERABILITY OVERVIEW

Microsoft Internet Explorer suffers from a vulnerability in its handling of 
certain drag-and-drop events.  As a result, it is possible for a malicious web 
site to predict and exploit the timing of a drag-and-drop operation such that 
any drag operation (including using scroll-bars) could potentially lead to the 
installation of arbitrary files in sensitive locations that may enable further 
system compromise.

III. TECHNICAL DESCRIPTION

As a result of recent updates to its drag-and-drop functionality, Internet 
Explorer now imposes a rigid set of restrictions on most drag-and-drop sources:

        * Input to the browser from other applications is not permitted.
        * Dragging an object from inside a frame is not permitted.
        * Dragging an HTML element from a top-level window will produce a 
security warning.

However, certain objects not derived from an HTML document (specifically, file 
objects within a folder view) remain draggable.  This gives rise to a potential 
race condition in the handling of user input.  If an attacker can persuade a 
user to drag any object within the top-level window that his/her site is 
contained in, malicious script can redirect these inputs to other top-level 
windows, potentially resulting in an unintended consequence such as file 
installation.

Proof-of-concept code has been developed that utilizes a pop-under window 
pointing to a malicious file share.  This window can be created using 
window.open() or other stealthier methods that are known to evade Internet 
Explorer's built-in pop-up blocking.  Focus is then returned to the opening 
window, where the user is encouraged to drag an object (image, link, etc.) in a 
seemingly "safe" fashion.

Immediately prior to this object being dragged, a mouseOver event is triggered 
that enables the attacker to (with a varying degree of success) predict the 
imminent drag attempt.  The pop-under can then be returned to focus by way of a 
window.blur() executed in the current window.  If the timing of the transition 
is accurate to a margin of error within a user's reaction time threshold, the 
user will unwittingly initiate a drag of a file from the pop-under instead of 
the object originally used as a lure by the attacker.

As soon as it transfers focus, the window with the original interactive content 
may set a timer (via window.setTimeout()) that returns focus to the window with 
a simple window.focus() call.  After a split-second delay, focus is returned to 
the interactive window.  At this point, on-demand alteration of CSS attributes 
can be used to display previously-hidden objects (such as inline frames).  
These objects serve as "drop target" windows and will initiate the copying of 
the file dropped from the (presumably malicious) pop-under window.

While Internet Explorer blocks hiding or resizing of certain "suspect" objects 
(IFRAMEs, for instance), so-called container objects (DIV, SPAN, etc.) suffer 
no such restrictions, even when they contain one of the objects in the former 
category.  The proof-of-concept code as developed simply stores a full-screen 
inline frame in a container initially marked with the "hidden" visibility style.

The pop-under window, in this instance, would be a folder on a malicious 
server.  This could be accessed via SMB (\\HOSTILESERVER\SHARE), FTP 
(ftp://hostileserver/somedirectory) or even HTTP (web folders) using certain 
link behaviors in combination with the click() method of a hyperlink object.  
In the third case, the pop-under would be targeted to an HTML document 
initally, which would then open the web folder containing hostile content.

The path to the drop target (the hidden frame in the original window) requires 
a little more creativity.  Particularly in Windows XP Service Pack 2, Microsoft 
has done a fairly good job of locking down access to local resources.  The most 
interesting vector for the purposes of this attack is via the network 
redirector.  By using the IP address or machine name of the local system 
(typically obtainable via any number of means), such as:

        \\MACHINENAME\share

It becomes possible to access resources offered by the network redirector on 
the local system.  Of most interest is the "Scheduled Tasks" folder:

        \\MACHINENAME\Scheduled Tasks

Items dropped into this folder execute automatically at a system-determined 
time (3 AM local time in tests on Windows XP Professional Service Pack 2) each 
day as the user dropping the file.  Also of interest are common shares such as 
the administrative shares (C$, D$, etc.) and typical share names like 
"SharedDocs" on Windows XP.  In most cases, this is at least a partial 
functional equivalent to local file system access and is not subject to zone 
restrictions, even on Windows XP Service Pack 2.

IV. IMPACT

A malicious web site, with a minimum of social engineering, may be able to 
compromise user systems by triggering an unintended installation of malicious 
software.  Typical defense-in-depth measures may mitigate this issue.  For 
those who run Internet Explorer with administrative privileges, the impact of 
any successful exploitation is complete control of the affected system.  A 
malicious web site could install software that would add or delete privileged 
user accounts, alter, destroy or disclose the content of personal or otherwise 
sensitive files, record personal information or any number of other activities.

Users who do not browse with such high levels of privilege would be at a 
significantly reduced risk from exploitation of this vulnerability.  In the 
case of a user with limited privileges, this vulnerability could only be 
exploited by an attacker to install software that executes with the privileges 
of that user.

V. WORKAROUNDS

The following workarounds are believed at the time of this writing to be 
effective against the exploitation of this vulnerability in some form:

1. Set a Kill Bit on the Shell.Explorer Control
-----------------------------------------------

Setting a kill bit on this control will prevent Internet Explorer from 
displaying the rich folder view interface that gives rise to this attack.  For 
more information about setting kill bits, please see Microsoft Knowledge Base 
Article 240797:

        http://support.microsoft.com/kb/240797

The CLSID of this component as deployed on Windows XP is:

        {8856F961-340A-11D0-A96B-00C04FD705A2}

Tools to automate the process of setting this kill bit have been provided at:

        http://student.missouristate.edu/m/matthew007/tools/shellkill.zip
        PGP signature: 
http://student.missouristate.edu/m/matthew007/tools/shellkill.zip.asc

Included in this archive are an Administrative Template (.adm) and a VBScript 
file (.vbs) which implement this setting.  The Administrative Template also 
allows an administrator to work around a specific case of functionality loss 
caused by the implementation of this workaround.  Instructions on using both 
files are contained within the readme file in the archive.

IMPACT: This workaround will cause Internet Explorer to no longer render folder 
views for local directories, network file shares, FTP directories and web 
folders by default.  The ability to browse FTP directories in Internet Explorer 
can be restored by clearing the "Enable Folder View for FTP Sites" option in 
Internet Explorer's "Advanced" options.  However, this countermeasure is known 
to expose another security vulnerability that does not appear to have been 
fixed as of this writing:

        http://lists.grok.org.uk/pipermail/full-disclosure/2003-June/005321.html

For ordinary browsing purposes, the Windows Explorer tool is unaffected by this 
change.  This defensive measure has been successfully implemented in at least 
one commercial software product and tested on a significant scale prior to the 
release of this advisory.  Therefore, it is the belief of the author that 
potential loss of functionality *should* be minimal.  As with all measures, you 
are encouraged to test the impact of this workaround prior to making any 
decision about deployment.

2. Prevent Automatic Navigation to Local Intranet Zone (Windows XP SP2, Windows 
Server 2003 SP1)
------------------------------------------------------------------------------------------------

This workaround will prevent internet content in Internet Explorer from 
automatically navigating to URLs within the Local Intranet Zone.  This 
effectively prevents the introduction of malicious code to the local system via 
the network redirector.  To implement this workaround, follow these steps:

        1. In Internet Explorer's Tools menu, choose "Internet Options..."

        2. Select the "Security" tab and choose "Local Intranet"

        3. Click the "Custom Level" button

        4. Set the "Web sites in less privileged content zone can navigate into 
this zone" setting to "Disable" or "Prompt".

        5. Click OK to close any dialogs and optionally, close Internet 
Explorer.

IMPACT: This workaround will block or prompt before allowing any navigation to 
LAN resources from the Internet Zone.  Direct access to LAN resources continues 
to function normally.  As a result of this workaround, attempts to access local 
intranet content (for instance, web applications on corporate intranets) from 
web sites outside of the LAN will fail or produce prompts, depending upon the 
chosen setting.

3. Disable Active Scripting
---------------------------

This workaround will prevent internet content from executing script that could 
potentially cause the exploitation of this vulnerability.  To implement this 
workaround, follow these steps:

        1. In Internet Explorer's Tools menu, choose "Internet Options..."

        2. Select the "Security" tab and choose "Internet"

        3. Click the "Custom Level" button

        4. Set the "Active scripting" option to "Prompt" or "Disable".

IMPACT: This workaround will block or prompt before allowing web sites to 
execute any script statement.  Scripting in more-privileged zones (Local 
Intranet, Trusted Sites) continues to function normally.  Setting this option 
to "Prompt" may cause a significant increase in the number of security prompts 
received while browsing and may be ineffective in closing this vulnerability 
for users not capable of making an assessment of a web site's relative 
trustworthiness.

VI. MITIGATION RECOMMENDATIONS

1. 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.

2. Run Exposed Applications With Reduced Privilege
--------------------------------------------------

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.

VII. VENDOR RESPONSE

Microsoft was informed of this vulnerability on August 3, 2005.  Currently, the 
company has no plans to issue a security update to correct this vulnerability.  
Fixes for this issue are scheduled to be included in Service Pack 2 of Windows 
Server 2003 and Service Pack 3 of Windows XP.  Of particular note is that 
Windows 2000 users will *NOT* receive an update to correct this vulnerability.

Microsoft's internal risk-assessment concluded that this issue was not 
sufficiently serious to be fixed in a security bulletin.  This conclusion 
appears fundamentally inconsistent with the way related issues were handled by 
Microsoft.  In particular, the drag-and-drop vulnerability patched by MS05-013 
received an "Important" rating.

I disagree with the technical conclusion behind Microsoft's decision and I 
further find the timeframe of delivery and deployment for maintenance releases 
to be largely unsuitable for security fixes of any significant magnitude.  I 
find the harm this decision could potentially inflict upon down-level users 
(most importantly, users of Windows 2000) to be unjustified by the technical 
concern Microsoft has raised to me.  Microsoft also rejected a request that it 
consider the issue for inclusion in a later security update as a "Moderate" 
risk issue.

Due to Microsoft's noncommittal and generally unimpressive response to the 
issue, this advisory is being issued to inform users of this vulnerability such 
that defensive action may be taken as desired.

VIII. REFERENCES/STANDARDS

* CVE

The MITRE Common Vulnerabilities and Exposures (CVE) project has assigned the 
name CVE-2005-3840 to this issue.  Status information and related references 
for this candidate may be found at:

        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3840

* OSVDB

The Open Source Vulnerability Database (OSVDB) project has assigned OSVDB 
vulnerability ID #2707 to this issue.  Information will be available shortly 
after the publication of this advisory at the following URL:

        http://www.osvdb.org/displayvuln.php?osvdb_id=2707

* SecurityTracker

SecurityTracker has pre-assigned an alert number in its internal database to 
reference this issue.  Information will be available shortly after the 
publication of this advisory at the following URL:

        http://www.securitytracker.com/id?1015049

* SecurityFocus

SecurityFocus has pre-assigned BugTraq ID #15089 to reference this issue.  
Information will be available shortly after the publication of this advisory at 
the following URL:

        http://www.securityfocus.com/bid/15089

IX. ACKNOWLEDGEMENTS

* The Administrative Template file supplied in the workaround ZIP was authored 
by Steven Platt.

X. CONTACT

The author may be contacted via e-mail at mattmurphy@xxxxxxxxx

XI. LEGAL

This document is believed accurate based upon information available at the time 
it was written.  However, the information offered is offered in an AS-IS 
condition, without warranty.  By acting upon this information in any way you 
accept all responsibility for damage that may occur as a result.

This document may be reproduced in whole without limitation and in part 
provided that a full copy of the original document is readily accessible and 
the author of the document is duly acknowledged.


 




Copyright © Lexa Software, 1996-2009.