full-disclosure - safari dos

lists.openwall.net		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]

From: fulldisclosure at grant.x43.net (Grant Husbands)
Subject: safari dos

kang@...ecure.ws wrote:
> Original is here:
> http://www.insecure.ws/article.php?story=20031122012748282
> 
> 
> 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:

s='.';s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;
s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;
s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;s+=s;

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.

Regards,
Grant.