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
| ||
|
Message-ID: <001001c3b1b5$f7a3a600$3564a8c0@bwsint.com> Date: Sun, 23 Nov 2003 11:35:59 -0000 From: "Grant Husbands" <fulldisclosure@...nt.x43.net> To: <full-disclosure@...ts.netsys.com>, <bugtraq@...urityfocus.com> Subject: Re: 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Powered by blists - more mailing lists