299564 - Firefox freezes when rendering "javaprxy.dll" COM Object Exploit

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Pavel Penaz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050703 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050703 Firefox/1.0+

Firefox freezes when rendering "javaprxy.dll" COM Object Exploit. I'll attach
the testcase in a minute. Setting security flag in case it is exploitable.

Reproducible: Always

Steps to Reproduce:
1. view the attached testcase in Firefox

Actual Results:  
Firefox freezes and memory usage starts climbing very rapidly.

Expected Results:  
Cope with the situation in a more subtle way :)

Comment 1

[Pavel Penaz]

Attachment: testcase

testcase generated by the Perl script for the Microsoft Internet Explorer
"javaprxy.dll" COM Object Exploit..

Comment 2

[Pavel Penaz]

Attachment: testcase (text/plain)

Comment 3

[Brendan Eich [:brendan]]

Don't misassign bugs to the JavaScript Engine component of the Core product.  If
you don't know where to start, try the General component in the relevant app's
bugzilla product.

/be

Comment 4

[Brendan Eich [:brendan]]

I doubt this is a security bug.

/be

Comment 5

[Mike Connor [:mconnor]]

I can confirm that I get some insane memory usage with the testcase, Firefox
spiked at somewhere over a gig of memory used, cycling up and down.  That said,
this really constitutes a DoS which we don't really consider a "security" issue,
iirc.

FWIW, its just swapping that'll hose users.  With two gigs of memory in this
system, it barely slows things down here.

Comment 6

[Pavel Penaz]

OK, so someone please remove the security-sensitive flag - I can't.

Comment 7

[Brendan Eich [:brendan]]

What's using all that memory?  We trying to lay out a huge .exe as text/* ?

/be

Comment 8

[Daniel Veditz [:dveditz]]

Clearing flag: publicly announced by frsirt

Comment 9

[Daniel Veditz [:dveditz]]

*** Bug 300175 has been marked as a duplicate of this bug. ***

Comment 10

[WADA:World Anti-bad-Duping Agency]

Attachment: Modiefied testcase(text/html) of attachment 188128

Difference from test case of attachment 188128 [details].
 (A) Issue alert before "for (i=0;i<750;i++) memory[i] = block + shellcode;"
 (B) Issue prompt on each 80 loops of "for ... memory[i] = block + shellcode;"
 (C) Issue prompt before location.replace() which is placed after </html>
 (D) <object> tag is removed => Script and <p> only

Since length of saved data to memoty[i] is almost 256K bytes long,
40 times of the "for loop" at least consumes 10MB virtual storage.
(20MB for 80 times of loop, 188MB for 750 loops).
I think this is only a memory exaust phenomenon by huge data.

My test reslut is as follows(Celeron 600MHz, 128MB memory, 512MB swap area).
(1) Start Seamonkey(7/7 build), No extention is installed, Only one tab opened.

    Start Task Manager and watch virtual memory size & real memory size. 
(2) Load the modified test case => Virtual Storaze size = 20MB
(3) Alert => size of "block" is almost 256K bytes.
(4) On first prompt says 20MB data is saved in memory[i] in this 80 times loop
    => Virtual storage size increased to 60MB (40MB consumed)
    => Press "OK"
(5) On second first prompt(says total of 40MB data is saved in memory[i])
    => Virtual Storage increased to 100MB (40MB consumed additionaly)
    => Press "Cancel"
       (If try more, swap expansion occurs on my system.)
       (I don't know what will happen when Mozilla uses 400MB on my system.)
(6) Prompt for "location.replae()"
    => Press "OK"
    => Page is reloaded and alert of step(3) is issued
(7) Wait for a while
    => Virtual storage size decreased to 20MB. This is same size as initial.

If "Cancel" is pressed at step(6) and load completed normally, virtual storage
size remained 100MB(size at step(5)).
And if other page is loaded to this tab, virtual storage size remained 100MB.
But virtusl storege size was reduced to 20MB(initial size) when the tab was
closed.

I think this is only a memory exaust by huge data, although I can't say affect
by   "alert" or "prompt" in my modified test case.

I don't know whether "virtual storage increase was twice of saved date length"
is problem or not.
But I guess this is current design of memory management for JavaScript objects,
instead of memory leak.

Comment 11

[Eric Foley]

i can confirm that firefox 1.5 rc3 is affected.

Comment 12

[timeless]

[e-mail]: i don't know who you are, or why you think we wanted a confirmation or what kind of confirmation you're giving, but your comment added absolutely no value.

so far i see nothing wrong here.

Comment 13

[timeless]

the hang here is not related to java. we don't load java for this testcase because we don't know or care about that classid. java only comes into play when an activex control host (mshtml) honors the object tag.

Comment 14

[:Gijs (he/him)]

Not seeing a hang or *actual* memory difference (the dialog doesn't reflect reality in task manager or similar. As comment #13 noted, the clsid will just be ignored... marking this WFM. Please only reopen if you have new information.