This advisory describes two vulnerabilities that provide access to any
file stored in on a user's desktop system if it is running a vulnerable
version of Internet Explorer. These vulnerabilities can be used in
attacks combined with a number of insecure features of Internet Explorer
to provide remote access to locally stored files without the need for
any further action from the victim after visting a website controlled by
the attacker. The vulnerabilities are simple variations of bugs
disclosed previously in CoreLabs Security Advisories CORE-2008-0103 [1]
and CORE-2008-0826 [2]. Exploitation of these vulnerabilities requires
enticing users to click on URLs otherwise visit a malicious website
controlled by the attacker but no further user interaction is needed. As
a result an attacker would gain the ability to read any file stored on
the user's desktop system but will not be able to fully compromise it to
execute arbitrary code without restrictions.

The vendor has guidance on how to address these vulnerabilities in
Microsoft Security Advisory (980088):
http://www.microsoft.com/technet/security/advisory/980088.mspx

To prevent exploitation of these vulnerabilities the following
mitigations are possible:

. Run Internet Explorer with Protected Mode [3] turned ON if it is
supported by the operating system. This is default setting for the
Internet security zone on Windows Vista, Windows 7 and Windows Server
2008. Note that there may be specific scenarios where protected mode may
need to be turned off [4]
. Use Internet Explorer's Network Protocol Lockdown feature control
to restrict the 'file:' protocol to prevent HTML content from UNC paths
from running scripting or ActiveX controls. Note that Network Protocol
Lockdown may affect the functionality of Web applications that rely on
relaxed security configurations of IE.
. Set the Security Level setting to High for the Internet and Local
Intranet security zones to prevent IE from running scripts or ActiveX
controls.
. Disable Active Scripting for the Internet and Local Intranet zones
manually with a custom security setting.
. Use a different web browser to navigate untrusted web sites.

Additionally, disabling file sharing if it is not necessary and
filtering outbound SMB connections at the endpoint or network perimeter
are good security measures to prevent disclosure of sensitive
information such as valid user, system and domain names that could be
used to perform attacks that abuse the vulnerabilities described in this
advisory.

7. *Credits*

These vulnerabilities were discovered and researched by Jorge Luis
Alvarez Medina and Federico Muttis from Core Security Technologies.

8. *Technical Description / Proof of Concept Code*

The bugs in this advisory as well as a number of specific methods to
combine them with insecure Internet Explorer features are discussed in
the paper "Abusing Insecure Features of Internet Explorer"[5].
Exploitation of these vulnerabilities as well as others disclosed
previously was explained in a presentation at the BlackHat DC 2010
technical security conference [6]

8.1. *URLMON sniffing vulnerability*

In CoreLabs Security Advisory CORE-2008-0826 [2] a vulnerability that
allowed attackers to gain access to any file on the local filesystem of
a computer running vulnerable versions of Internet Explorer was
disclosed. During the vulnerability reporting process Core provided
Proof-of-Concept code to the vendor that successfully exploited the bug
on Internet Explorer 8 which at the time was deemed not vulnerable by
Microsoft because the bug had been patched prior to RTM. Upon further
investigation, the vendor determined that the proof-of-concept provided
by Core was actually exploiting a different bug than the one originally
reported and therefore it should be considered a separate security
issue. The URLMON sniffing vulnerability refers to the variant
discovered in the CORE-2008-0826 time line. When loading a local file
Internet Explorer's HTML rendering engine [7] will only check its MIME
type to see if it is a positive match on the files it can handle. For
unknown types that are treated as HTML because they've been referred to
by a redirection, content type determination will default to 'text/html'
in absence of a type explicitly set by the content source. In the case
of non-html files for which there isn't an explicit content-type set,
URLMON will default to the 'text/html' type as suggested from the
redirection. As a result Internet Explorer will end up loading non-html
local files and rendering them as HTML and running any scripting code
included in the file in the context of the Security Zone assigned to the
content's source.

8.2. *Dynamic OBJECT tag vulnerability*

Microsoft's June 2009 Cumulative Security Update for Internet Explorer
[8] included a patch to fix the bug reported in CORE-2008-0826. The fix
was implemented as a modification to the MIME-type detection method when
loading content specified in an 'OBJECT' tag. Thus, the contents of the
index.dat file will not be rendered and shown to an Internet Explorer
user if it is directly referenced from a webpage with the following HTML
code:

. 2009-04-17:
Core Security Technologies sends proof-of-concept code for the URLMON
sniffing vulnerability in IE8 to Microsoft. The code is deemed as an
exploit variant for Internet Explorer bug that has already been patched
in IE 8 but its part of an ongoing report for other IE versions.

. 2009-06-01:
Microsoft says that the PoC corresponds to a separate bug than the one
reported in CORE-2008-0826. On a conference call Core Security
Technologies indicates that it considers the bug just a variant of the
previously reported one. Microsoft replies that although both cases
appear to expose the same functionality the actions are actually
controlled by different code and that the differences are significant
enough to consider this a separate issue. Microsoft will further
investigate and address it in a separate case.

. 2009-08-12:
Microsoft's MSRC acknowledged the bug report and opened a new case.

. 2009-08-31:
Core asks for an update and reminds MSRC that September 8 2009 is the
planned public disclosure date.

. 2009-08-31:
Microsoft replies agreeing that the reported bug is a variant of one
previously reported by Core that was fixed in June 2009. Microsof
indicates that all the solutions attempted so far did not prove
effective and that it currently does not have an update to track towards
a fix time. Asks if Core is still on track to disclose it in September
2009.

. 2009-09-03:
Core tells Microsoft that it moved the publication date to October 13
2009 and asks for the complete list of vulnerable platforms. Given that
no security fixes for Internet Explorer are planned for September and
that the reported bugs are simple variants of others that have been
fixed before Core feels confident that the new release date should be
appropriate to solve these issues.

. 2009-09-04:
Microsoft thanks Core for postponing publication and says that it is
still discussing the fix plan and release date with the IE team and that
it will get back to Core in a week with the list of vulnerable platforms
and estimated patch release date.

. 2009-10-09:
Received a summary from Microsoft with an update on all open cases with
Core. Internet Explorer cases appear listed as "working with product
team to determine fix and release date. Earliest potential ship date for
a fix is February 2010".

. 2009-10-23:
Core sends email to MSRC indicating that publication of the advisory has
been re-scheduled to November 10 2009 and it is open to delaying it
further up to the second Tuesday of December 2009 if MSRC is willing to
provide: a)detailed technical explanations of the bugs, b)the full list
of vulnerable platforms and c)a firm commitment to a release date for
the fixes. Core also says that if Microsoft can not target the next IE
patch release cycle, Core would rather publish the advisory to let other
parties address the risk with alternative fixes or mitigations. The
advisory will include the dynamic object tag bug as well as the URLMON
sniffing vulnerability from the previous vulnerability report that is
pending a fix.

. 2009-11-02:
Update from MSRC saying that it is collecting information and will send
a response by Friday Nov. 6.

. 2009-11-06:
Core requests a status update

. 2009-11-06:
MSRC indicates that it will provide an update on Monday Nov. 9

. 2009-11-09:
MSRC sends a status update with detailed descriptions about both bugs,
the list of vulnerable platforms and says that it is still working on a
tentative fix plan for one of the vulnerabilities. In the case of the
other bug, Microsoft is targeting February 2009 to release the fix given
that releasing updates in November and December may impact customers due
to the typical high e-commerce in those months.

. 2009-12-12:
Core sends email to MSRC saying that advisory publication was now
re-scheduled to February 9th, 2010 and asks if Microsoft is on track to
release the fixes according to what was stated in previous
communications. Core notes that Jorge Luis Alvarez Medina has just
received confirmation from the BlackHat Technical Security conference
that his submission for a talk discussing these bugs was accepted. His
presentation is scheduled for the first week of February and the
advisory publication was re-scheduled to a week after on February 9th
assuming that Microsoft will issue patches on the same date.

. 2010-01-06:
Received a summary from Microsoft with an update on all open cases with
Core.

. 2010-01-06:
Core reminds MSRC that the advisory disclosing two IE bugs pending
resolution will be published on Feb. 9 2010 as noted in an email on
December 12 2009.

. 2010-01-22:
Microsoft releases a Cumulative Security Update for Internet Explorer
ahead of the regular patch release cycle. The update fixes several bugs
but does not include fixes for the two IE cases tracked in this
advisory. Core asks MSRC if Microsoft is planning to release another
security update for IE during February and indicates that if no further
updates are planned Core will publish this advisory simultaneously with
the discoverer's presentation at the BlackHat security conference.

. 2010-01-22:
Email from MSRC requesting a conference call to talk about the
presentation at the BlackHat DC conference in February

. 2010-01-25:
On a conference call with Core's Security Advisories team, MSRC
indicates that fixes for the bugs will be released at some date in the
future. Core reminds MSRC that the corresponding security advisory will
be published on Feb. 3 on the same date that Jorge Luis Alvarez Medina
will disclose details about the bugs and attack vectors at the BlackHat
conference. MSRC requests a preview of the presentation slides. Core
requests a preview of Microsoft's communications guidelines regarding
Core's upcoming advisory and presentation.

. 2010-02-02:
BlackHat presentation slides sent to MSRC

. 2010-02-02:
Final draft of the advisory sent to Microsoft. Vulnerability identifiers
requested from Mitre and SecurityFocus.com

CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs.

12. *About Core Security Technologies*

Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.

13. *Disclaimer*

The contents of this advisory are copyright (c) 2009 Core Security
Technologies and (c) 2009 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.

14. *PGP/GPG Keys*

This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.a
sc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)