From idlabs-advisories@idefense.com Mon Feb 28 11:24:13 2005 From: idlabs-advisories@idefense.com To: idlabs-advisories@idefense.com Date: Mon, 28 Feb 2005 10:34:35 -0500 Reply-To: labs-no-reply@idefense.com Subject: [Full-Disclosure] 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 ::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@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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html