471113 - Mozilla Firefox 3.0.5 Zero Buffer Check Memory Exhaustion and Leaking

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Aditya K Sood]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.36 Safari/525.19
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) 

Mozilla 3.0.5 exhaust System Memory with Zero Check on Buffer Supplied to any Event or Object.The Loop is just allocating buffer but the objects instance is failed to handle the buffer there by leading memory exhaustion. Firefox will not get affected when a simple script buffer is allocated until some event or object is executed with it.




Reproducible: Always

Steps to Reproduce:
<form name="leak_obj">
<input type="text" name="vuln_obj">

<script>
var object="";
for(temp=0;temp<9000000;temp++)
{
	object= object+"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
}

document.leak_obj.vuln_obj.value=object;

</script>
Actual Results:  
Memory Exhaustion and Leaking
100% CPU Usage
High End Denial of Service

Expected Results:  
The execution of script should be stopped after performing a buffer check.

Comment 1

[Martijn Wargers (dead)]

Does it crash for you? Do you have a breakpad id? http://kb.mozillazine.org/Breakpad

Comment 2

[Aditya K Sood]

This POC points at memory exhaustion and leaking straight forward. It does not crashes for me as such but with no point of time the CPU state changes. The CPU starts making barred sounds.

Comment 3

[timeless]

so, it doesn't crash.

and you don't seem to have a definition of leaking.

fwiw, i actually got one interesting nibble:

Heap corruption detected at 04B14008
but i'm not certain that's related, i think it had to do w/ something else that happened to my system.

we seem to be clean on linux

this is a very slow way to run out of memory (at least w/ a debugger)

text/html,<form%20name="leak_obj"><input%20type="text"%20name="vuln_obj"><script>var%20object="";for(temp=0;temp<9000000;temp++){object=object+"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";}document.leak_obj.vuln_obj.value=object;</script>

offhand, given that it feels like this will require heatdeath before my computer runs out of memory, i'd rather disclose this and say there's nothing here.

the reporter hasn't shown a leak. or explained anything.

Comment 4

[Aditya K Sood]

Well this is not an issue that is left to be closed here.
Let me get to the point one by one.

1. From the design perspective even if a script or value that is passed to a required object in a web page there must be a buffer check. this alert check should comes to play when ever a script is trying to utilize system resources more than a specific limit. In this case with Firefox 3.0.5 this is not happening. This is one vector but this can be used in different ways to play with this bug.

2. When a system starts consuming memory at fast rate it is a point of introspection. 

3. Different systems have different behavior with the inbuilt browser components
whether its linux, vista or windows XP. The report is specific to windows XP SP2/SP3 versions.

4. Regarding the memory leak. There is a possibility because its a case of somewhat memory inline. One can increase the frequency with increase in limit of required loop and passing value to the object which is input box in this case.

5. As you mentioned there is an indication of heap corruption so the vector is
different. This was noticed too.

The point of our discussion is to look for solution and the cause for it.

will look forward for your views.

Comment 5

[timeless]

opening. this bug isn't going anywhere without help.

Comment 6

[aravindm]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4) Gecko/20100407 MozillaDeveloperPreview/3.7a4
Please update if you are able to still reproduce with the latest nightly build  ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/

Comment 7

[Kevin Brosnan]

I left this page open on a clean profile for about an hour. Firefox's memory usage about doubled from 35mb to 61mb loading the page, trended upwards to about 80mb and now is sitting at 73mb.

Error: allocation size overflow
Source File: http://www.secniche.org/moz305/poc.html
Line: 16

Looks like the JavaScript engine kills the script before it can run away.

Comment 8

[Kevin Brosnan]

The build was. Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100803 Minefield/4.0b3pre

Comment 9

[jackie miller]

Attachment: javacpl.exe

java does not work on pogo and i do not have the key to get it working

Comment 10

[Terrence Cole [:terrence]]

In current builds, this reports the correct "allocation overflow" basically instantly. Not that it matters: user scripts are allowed to do whatever they want, no matter how bad an idea it is.