lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 23 Nov 2003 11:35:59 -0000
From: "Grant Husbands" <>
To: <>, <>
Subject: Re: safari dos wrote:
> Original is here:
> Safari will never exit a loop in javascript. Since javascript isn't
> executed in a thread, this cause a DoS (Safari crashes).

It should be noted that it's relatively easy to DoS most JS
implementations, anyway. For example, the following loop should cause
several browsers to become non-responsive and use as much RAM as they
can (they could feasibly recover, but I've not seen a browser do so):

s='.'; // Consume all (32-bit machines') RAM and more.
for (var i=0;i<32;++i) s+=s;

Or, to get around the fact that browsers detect back-jumps, just use
a similar trick to make the delay so long that the user thinks their
browser will not respond (this script mostly consumes CPU time,
rather than RAM):
b='';a="b=b+' ';"
for (var i=0;i<15;++i) a+=a;
// Above line creates a 64MB script
// Now run the 64MB script, 100,000 times
for (var i=0;i<100000;++i) eval(a);

The issue is not easily avoidable when browsers detect infinite loops
by the number of back-jumps that occur. Work-arounds could be
prescribed for these specific instances, but more attacks of this
form can always crop up, IMO.

As a slightly better fix, though (and one that may have been
implemented elsewhere), it might be better to check the time since
the script started, on each back-jump. That could cause both of the
above examples to exit much sooner. Also, the scheme could be altered
such that back-jumps aren't the only times at which things are
tested, but the compiler inserted a test every 100 bytecodes, or
something like that.

Unfortunately, the first script could be rewritten as follows, to get
around such a scheme:


Perhaps there should be a size limit on strings, too.

Please note that I've only tried these on WinXP, in Mozilla and IE,
but they're unlikely to be specific to any particular platform.

If the above information might be useful to browser writers that
don't subscribe to these lists, could someone please pass this
message on?  Thanks.


Full-Disclosure - We believe in it.

Powered by blists - more mailing lists