355134 - bad javascript results in total freeze

Status: RESOLVED WONTFIX

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

Description

[Thorben Krueger]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1) Gecko/20060918 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1) Gecko/20060918 Firefox/2.0

i am going to attach the corresponding file later

Reproducible: Always

Steps to Reproduce:
1.open firefox
2.call up file
3.try to do anything else

Actual Results:  
firefox freezes

Expected Results:  
the script should be identified as slow running and the user should at least be able to manually terminate it

Comment 1

[Thorben Krueger]

Attachment: this file causes firefox to freeze

warning: this html-file freezes firefox

Comment 2

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061002 BonEcho/2.0 ID:2006100204
I see this too.

Comment 3

[Thorben Krueger]

Does not seem to be OS-dependent, OSX version hangs, too.

Comment 4

[Andrej Schoeke]

I can confirm this bug. I experienced it a while ago and still, it is working and leads to a full crash!

Comment 5

[Thorben Krueger]

Trivia: http://canuco.de/bad-js.html

Comment 6

[Thorben Krueger]

Firefox 3.0 alpha also freezes. This concerns EVERY version of firefox I tried.

Comment 7

[Bob Clary [:bc] (inactive)]

With

function repeatStuff() {	
  do {
  } while (setTimeout('true',10000));
}

or even

function repeatStuff() {	
  do {
  } while (true);
}

You will get the slow script dialog which allows you to kill the script. I think the bug here is that the XMLHttpRequest prevents the slow script dialog from appearing. I don't think this is js engine fodder. jst?

Comment 8

[Thorben Krueger]

just tested with Gran Paradiso Alpha 4. browser freezes, consumes cpu power and eats up more and more memory.

Comment 9

[Bob Clary [:bc] (inactive)]

If you are going to switch components, you need to switch owners as well.

Comment 10

[Thorben Krueger]

(In reply to comment #9)
> If you are going to switch components, you need to switch owners as well.
> 

thanks

I can savely be considered a frickin bugzilla n00b... indeed, iirc, this is my second bugreport ever.

Comment 11

[Brian Crowder]

I'm of the opinion that this (and other easy DoS type attacks) should not block 1.9.  Also, this does not appear to be a JS-engine bug, since it seems to rely on setTimeout and XMLHttpRequest.

Comment 12

[Thorben Krueger]

Should it really remain this easy to achieve a DoS in firefox? Maybe I should switch to opera then... Because for me a freeze is almost as bad as a crash.
You could argue, that this is obviously true for servers. But think about it:
You can do serious damage to people's workflow just by forcing them to reset their browser. (And it isn't even that easy. You have to kill the process manually...)

Just out of curiosity: How can a bug relying on bad JS _not_ be a JS-engine bug?


(In reply to comment #11)
> I'm of the opinion that this (and other easy DoS type attacks) should not block
> 1.9.  Also, this does not appear to be a JS-engine bug, since it seems to rely
> on setTimeout and XMLHttpRequest.
> 

Comment 13

[Brian Crowder]

Thorben:  I'm not saying we shouldn't fix the bug.  I'm saying that it shouldn't supersede more important work.

To answer your second question:  the bug does not rely on "bad JS", there's nothing inherently bad about your JavaScript here.  The bug relies on the interaction of various DOM methods /called from JS/, which is something entirely different.

Comment 14

[Johnny Stenback (:jst)]

(In reply to comment #12)
> Should it really remain this easy to achieve a DoS in firefox? Maybe I should
> switch to opera then... Because for me a freeze is almost as bad as a crash.
> You could argue, that this is obviously true for servers. But think about it:
> You can do serious damage to people's workflow just by forcing them to reset
> their browser. (And it isn't even that easy. You have to kill the process
> manually...)

Any website that wants to lock up any browser can fairly trivially do so. Fixing this bug will only plug one of many other DoS attacks, so fixing this bug in and of itself is not critical. Fixing the problem over all would be worth while looking into, especially if sites doing browser DoS attacks get common, but given the lack of return on something like that (opposed to stealing credit card info, or taking over a computer etc) it's not something I see happening any time soon.

Comment 15

[Thorben Krueger]

Also freezes latest Release Candidate of Firefox 3

Comment 17

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 18

[Timea Cernea [:tbabos][inactive]]

Still reproducible on latest MacOS 10.15 on all latest Firefox versions.

Comment 19

[Jens Stutte [:jstutte]]

As of comment 14 from 14 years ago, there is not much we can/should do here.