Message-ID: <FB24803D1DF2A34FA59FC157B77C970503E24A5F@idserv04.idef.com>
From: idlabs-advisories at idefense.com (idlabs-advisories@...fense.com)
Subject: iDEFENSE Security Advisory 02.28.05: Mozilla
	Firefox and Mozilla
	Browser Out Of Memory Heap Corruption Design Error

Mozilla Firefox and Mozilla Browser Out Of Memory Heap Corruption Design 
Error

iDEFENSE Security Advisory 02.28.05
www.idefense.com/application/poi/display?id=200&type=vulnerabilities
February 28, 2005

I. BACKGROUND

Mozilla is an open-source web browser, designed for standards 
compliance, performance and portability. Further information about the 
browser is available at:

    http://www.mozilla.org

II. DESCRIPTION

Remote exploitation of a design error in Mozilla 1.7.3 and Firefox 1.0 
may allow an attacker to cause heap corruption, resulting in execution 
of arbitrary code.

The vulnerability specifically exists in string handling functions, 
such as nsCSubstring::Append, which rely on functions in the file 
mozilla/xpcom/string/src/nsTSubstring.cpp. Certain functions, such as 
nsTSubstring_CharT::Replace() fail to check the return value of
functions which resize the string.

xpcom/string/src/nsTSubstring.cpp:

[1] size_type length = tuple.Length();

    cutStart = PR_MIN(cutStart, Length());

[2] ReplacePrep(cutStart, cutLength, length);

[3] if (length > 0)
      tuple.WriteTo(mData + cutStart, length);


At [1], length is set to the length of the string to be copied, which
is the passed to ReplacePrep() at [2]. If the reallocation performed by
this function fails sets mData to a fixed address.

            mData = NS_CONST_CAST(char_type*, char_traits::sEmptyBuffer);
            mLength = 0;

The value of sEmptyBuffer is set in xpcom/string/src/nsSubstring.cpp:

static const PRUnichar gNullChar = 0;

const char*      nsCharTraits<char>     ::sEmptyBuffer = (const char*) &gNullChar;

As the return value is not checked, if the function fails mData is
pointing at a known memory location. By causing memory to be consumed
until an out of memory condition occurs, and controlling the value of
the string to append, it is possible at [3] to cause arbitrary data to
be placed is a known location, allowing execution of arbitrary code.

This vulnerability would rely on both knowing the version of the
browser, which could be obtained from the User-Agent string passed to a
malicious server, and being able to cause memory exhaustion. It may be
possible to cause memory exhaustion remotely by either sending a large
amount of data to the client in the headers, which would require a large
amount of bandwidth or by using compression to reduce the amount of data
that needs to be sent to the client, either via a server module like the
Apache httpd mod_deflate, or a file such as a ZIP file referenced by a
jar: URI. It also may be possible to use a javascript to allocate enough
memory to trigger this vulnerability.

As this vulnerability is triggered in an out of memory condition, it may
be easier to exploit on systems which have restricted the amount of
memory a user or process may use.

III. ANALYSIS

Remote exploitation of this vulnerability may allow execution of 
arbitrary code with the privileges of the logged in user. A failed 
exploitation attempt may result in the browser crashing.

IV. DETECTION

iDEFENSE Labs have confirmed The Mozilla Organization's Mozilla 1.7.1 
and 1.7.3, as well as Firefox 0.10.1 are vulnerable to this
issue. A check on the source code for Firefox 1.0 suggests it is also
vulnerable. It is suspected that all previous versions of both browsers
are vulnerable.

V. WORKAROUND

iDEFENSE is currently unaware of any effective workarounds for this 
vulnerability.

VI. VENDOR RESPONSE

Vendor advisory:
   http://www.mozilla.org/security/announce/mfsa2005-18.html

Raw bug report:
   https://bugzilla.mozilla.org/show_bug.cgi?id=277549

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0255 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

02/09/2005  Initial vendor notification
02/09/2005  Initial vendor response
02/28/2005  Coordinated public disclosure

IX. CREDIT

Ga?l Delalleau is credited with discovering this vulnerability.

Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp

Free tools, research and upcoming events
http://labs.idefense.com

X. LEGAL NOTICES

Copyright ? 2005 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice@...fense.com for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.

Powered by blists - more mailing lists