Closed Bug 281701 Opened 20 years ago Closed 20 years ago

[IDEF0799] out of memory heap corruption in xpcom/string

Categories

(Core :: XPCOM, defect)

defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 277549

People

(Reporter: dveditz, Unassigned)

References

()

Details

(Whiteboard: [sg:dupe 277549])

iDEFENSE reports the following problem found by Gaël Delalleau
--------------------------------------------------------------
Mozilla Firefox and Mozilla Browser Out Of Memory Heap Corruption Design 
Error Vulnerability

iDEFENSE Security Advisory XX.XX.05
http://www.idefense.com/application/poi/display?type=vulnerabilities
MMM DD, 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);

    if (length > 0)
[3]   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 memmory 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 Firefox 0.10.1 are vulnerable to this
issue. A check on the sourcecode 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

[Quoted vendor response if available. Otherwise include vendor fix
details.]

VII. CVE INFORMATION

A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.

VIII. DISCLOSURE TIMELINE

02/09/2005  Initial vendor notification
XX/XX/2005  Initial vendor response
XX/XX/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

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@idefense.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.
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
Yes, this is covered by bug 277549
Depends on: 277549

*** This bug has been marked as a duplicate of 277549 ***
No longer blocks: sg-ff101, sg-tb101, sg-moz176
Status: NEW → RESOLVED
Closed: 20 years ago
No longer depends on: 277549
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
Resolution: --- → DUPLICATE
Whiteboard: [sg:dupe 277549]
Group: security
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.