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




14 years ago
6 years ago


(Reporter: pavel.penaz, Unassigned)



Windows XP

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:dos], URL)


(3 attachments)



14 years ago
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

14 years ago
Posted file testcase
testcase generated by the Perl script for the Microsoft Internet Explorer
"javaprxy.dll" COM Object Exploit..

Comment 2

14 years ago


14 years ago
Keywords: testcase
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.

Assignee: general → nobody
Component: JavaScript Engine → General
Product: Core → Firefox
I doubt this is a security bug.

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,

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

Comment 6

14 years ago
OK, so someone please remove the security-sensitive flag - I can't.
What's using all that memory?  We trying to lay out a huge .exe as text/* ?

Group: security
Ever confirmed: true
Clearing flag: publicly announced by frsirt
Whiteboard: [sg:dos]
*** Bug 300175 has been marked as a duplicate of this bug. ***
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

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

14 years ago
i can confirm that firefox 1.5 rc3 is affected.
QA Contact: general → general


13 years ago
Blocks: 353557

Comment 12

13 years ago 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

13 years ago
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.
No longer blocks: 353557

Comment 14

6 years ago
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.
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.