malicious javascript loop code renders browser unusable--you have to kill the process




14 years ago
14 years ago


(Reporter: Timmy Douglas, Assigned: Blake Ross)


Firefox Tracking Flags

(Not tracked)





14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040404 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040404 Firefox/0.8

here is the code i stumbled on, and i made the page above as an example to
demonstrate it. i believe this code should be run in a different thread or
something so i could atleast close the tab and the page would be gone without it
crashing my browsing session. i use the tabbrowsing extension and i have popups
off so the window open call isn't the problem--it's that it just locks up the
gui and i can't do anything to stop it.

{ var iCounter = 0; while (true) {"http://about://","CRASHING" +
iCounter,"width=1,height=1,resizable=no"); iCounter++; }}

Reproducible: Always
Steps to Reproduce:
1. execute the code

Actual Results:  
browser doesn't respond to keypresses, mouse events, and the gui is never repainted.

Expected Results:  
remained responsive, so i could close the page or have some javascript abort
button that stops running javascript.

I think IE freezes on this code too... My roommate uses IE and I laughed at him
and then tried it with firefox, and well, I couldn't really laugh at him because
mozilla doesn't do better.


Build platform

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7) 	-Wall -W
-Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -mcpu=athlon-xp -pipe
-Wno-return-type -w -Wno-return-type -w -Wno-return-type -w -s -fforce-addr
-pthread -pipe
g++ 	gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7) 	-frtti
-fno-handle-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long
-mcpu=athlon-xp -pipe -Wno-return-type -w -Wno-return-type -w -Wno-return-type
-w -s -fforce-addr -fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --enable-optimize=-O2 --disable-composer --with-x
--with-system-jpeg --with-system-zlib --with-system-png --with-system-mng
--disable-mailnews --disable-calendar --disable-pedantic --disable-svg
--enable-mathml --without-system-nspr --enable-nspr-autoconf --enable-xsl
--disable-ipv6 --enable-crypto --with-java-supplement --with-pthreads
--with-user-appdir=.phoenix --disable-jsd --disable-accessibility
--disable-tests --disable-debug --disable-dtd-debug --disable-logging
--enable-reorder --enable-strip --enable-strip-libs --enable-cpp-rtti
--enable-xterm-updates --disable-ldap --disable-toolkit-qt
--enable-toolkit-gtk2 --enable-default-toolkit=gtk2 --disable-toolkit-gtk
--enable-xft --disable-freetype2 --enable-xinerama=no

Comment 1

14 years ago
Firefox freezed for a second or two and they i get a confirm dialog asking me if
I want to abort the script that is causing this freeze.

it might take longer on some systems, but Mozilla will detect a loop asking if 
you want to abort the script.  In some cases this will take a minute or two.  
Please let us know if that does not happen.
QA Contact: mconnor

Comment 3

14 years ago
Well, actually, you're right, I do get a popup that lets me cancel the
javascript . However, it comes up after about 4 minutes and 10 seconds making it
pretty useless. I think any user would have killed the process by then.
Espically because it didn't even repaint in that time--giving it the
"crashed-process" look. I'm running this on like a 1.4GHz with 512MB ram, so
it's probably not because i have a slow computer. I don't think this cancel
popup is the way to solve script problems... 
four minutes is longer than in should take, it took about 10-15 seconds here,
dunno what's different on your build.  What about an official nightly? (not a
CVS pull with custom options)  If you can suggest a way of predicting code that
will loop endlessly before it even gets executing, I'm sure it would be nice to

btw, if you open Privacy under Options, does your build crash?  try it and I'll
tell you why later :)

Comment 5

14 years ago
no, opening the privacy options doesn't crash my build (i tried expanding and
collapising all the options). the thing is... i don't understand why it would be
1-2 seconds on one computer, and 10-15 on someone elses, and more on mine.

i don't think the prediction code should be allowed to make you wait with an
unusable browser for an unpredictable amount of time. i believe the user should
always have control to abort an action at their will and not after the browser
decides that it is ready to abort the action. basically all you would need to do
is check to see if the user pressed stop or esc, and if that happens, stop
executing code. unfortunately, the browser is too "locked up" to respond to

i guess i have to debate now whether this turns this bug report into a
enhancement request or if it still is a problem for some people... sorry, i'm
not really in the mood to try another build now so we'll just have to leave it
as it is. thanks for the prompt replies.

with regard to being able to manually terminate the javascript... that's
something far beyond the scope of this bug (bad JS hanging the UI, unfortunate
byproduct of XUL front ends, known issue)

there has been enhancements in the detection code since 1.6, had some testing
done by some other people, all got the warning within 15 seconds, which is
reasonable enough, there is still ongoing work to detect these loops sooner, but
the balance is not screwing up intensive scripts in stopping these types of scripts.

Resolving WORKSFORME based on testing with trunk, if you want to go looking for
the bugs dealing with the logic I'm sure there are plenty.
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME

Comment 7

14 years ago
This looks like a true bill,

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040417

Something like 13 minutes before the cancel dialog

that's really bizarre timing.  I wonder what's different about your builds than
everyone I had test?  In any case, other than continued work on the logic, this
isn't going to get any better without fixing the "JS executes in the UI thread" bug.

Feel free to fix that, if you have a few months to spare :(
You need to log in before you can comment on or make changes to this bug.