555303 - Firefox 3.6.x Remote Denial of Service Exploit Vulnerability

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Orlando Barrera II]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)

There are several bugs which are present while fuzzing my POC, so I can not be very specific about the deatils.


Reproducible: Always

Steps to Reproduce:
Run the js code.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

This seems to just crash with OOM though according to the comments in the JS it triggered a DEP violation.

Comment 3

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

You can also try to reproduce in Firefox 4 Beta 8 or later, there are many improvements in the new version, http://www.mozilla.com/en-US/firefox/all-beta.html

Comment 4

[Reed Loden [:reed]]

This needs to be re-triaged. Running the PoC in comment #1 crashes me within a few seconds or less.

Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20101231 Firefox/4.0b9pre

bp-56e88412-6f85-4914-8125-93c322101231

Comment 5

[Reed Loden [:reed]]

Hmm, this does seem to be OOM'ing, but breakpad is completely useless. I noticed this on the command line:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Also occasionally getting this:

ExceptionHandler::GenerateDump waitpid failed:No child processes

Comment 6

[Boris Zbarsky [:bzbarsky]]

> but breakpad is completely useless.

It's generally useless on OOM, yes, since it runs in the same process and hence has no memory to work with.

Comment 8

[Daniel Veditz [:dveditz]]

"testcase" because we've got the reporter's testcase saved, but "testcase-wanted" because we'd like something that reliably caused the DEP violation rather than all the OOM and null-deref "DoS" crashes we're seeing.

Comment 9

[Josh Aas]

Can someone run the test case we have a significant number of times (25+?) using Firefox 9 and see if we still have a problem, and if so, do we ever get the DEP violation? Even without a reliable DEP violation test case we should still be able to determine if this is an issue in the most recent release.

Comment 10

[Josh Aas]

The test case doesn't crash or seem to have any impact at all on Firefox 9 on Windows 7. I ran it for over a minute.

Comment 11

[Josh Aas]

No impact on Firefox 8 on Fedora 15 Linux either.

Comment 12

[Josh Aas]

I crashed in under 10 seconds using Firefox 3.6.25 in a Windows 7 VM. I think it's safe to say that the only supported version affected by this is 3.6.25.

Comment 13

[Al Billings [:abillings - ex-MoCo]]

1.9.2 is being end of life'd now and this doesn't affect current versions of Firefox, including the ESR. 

We should resolve this as "won't fix" now.

Comment 14

[Jesse Ruderman]

"wontfix" is a bit strong, i'd go with "incomplete".

If we want to be more sure that the bug doesn't exist on trunk, we could ask Christian to run his OOM tool on the testcase ;)

Comment 15

[Al Billings [:abillings - ex-MoCo]]

Sounds good to me. Christian, can you do this?

Comment 16

[Christian Holler (:decoder)]

(In reply to Al Billings [:abillings] from comment #15)
> Sounds good to me. Christian, can you do this?

I'm on it. This required some manual work because my tool isn't meant for tests like this, but it's testing ~1200 callers right now. That'll take quite some time.

Comment 17

[Daniel Veditz [:dveditz]]

Reopening while we wait for the results of comment 16

Comment 18

[Daniel Veditz [:dveditz]]

decoder: any results on comment 16?

Comment 19

[Christian Holler (:decoder)]

(In reply to Daniel Veditz [:dveditz] from comment #18)
> decoder: any results on comment 16?

I haven't been able to find any new bugs here (though that doesn't mean there is none...)

Comment 20

[Al Billings [:abillings - ex-MoCo]]

(In reply to Christian Holler (:decoder) from comment #19)
> 
> I haven't been able to find any new bugs here (though that doesn't mean
> there is none...)

How much more testing do you plan to do?

We did think this was 1.9.2 only (probably).

Comment 21

[Christian Holler (:decoder)]

(In reply to Al Billings [:abillings] from comment #20)
> (In reply to Christian Holler (:decoder) from comment #19)
> > 
> > I haven't been able to find any new bugs here (though that doesn't mean
> > there is none...)
> 
> How much more testing do you plan to do?
> 
> We did think this was 1.9.2 only (probably).

I don't feel like spending further resources here will be helpful at all. I'm also not currently doing other OOM testing because I'm waiting for some bugs to be fixed first. Especially if this is 1.9.2. only then I don't think it's worth pursuing.

Comment 22

[Al Billings [:abillings - ex-MoCo]]

Well, as comment 14 says, we want to make sure this isn't present on trunk. You ran the tests on trunk, Christian?

Comment 23

[Christian Holler (:decoder)]

(In reply to Al Billings [:abillings] from comment #22)
> Well, as comment 14 says, we want to make sure this isn't present on trunk.
> You ran the tests on trunk, Christian?

I tested this only on trunk actually, yes.

Comment 24

[Al Billings [:abillings - ex-MoCo]]

I think we should resolve this and never speak of it again.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Any reason not to resolve this as WONTFIX?

Comment 26

[Josh Aas]

(In reply to Jonas Sicking (:sicking) from comment #25)
> Any reason not to resolve this as WONTFIX?

Sounds good to me. I'll also clear the attachments and opening up this bug.