Closed
Bug 281701
Opened 20 years ago
Closed 20 years ago
[IDEF0799] out of memory heap corruption in xpcom/string
Categories
(Core :: XPCOM, defect)
Core
XPCOM
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.
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
Comment 1•20 years ago
|
||
same as bug 277549?
Reporter | ||
Comment 2•20 years ago
|
||
Yes, this is covered by bug 277549
Reporter | ||
Updated•19 years ago
|
Group: security
Reporter | ||
Comment 4•18 years ago
|
||
The iDEFENSE advisory ended up here: http://idefense.com/intelligence/vulnerabilities/display.php?id=200
Updated•3 years ago
|
Component: String → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•