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
| ||
|
Date: Tue, 3 Mar 2009 10:21:23 +0100 From: Michal Zalewski <lcamtuf@...edump.cx> To: nick@...us-l.demon.co.uk Cc: full-disclosure <full-disclosure@...ts.grok.org.uk> Subject: Re: Apple Safari ... DoS Vulnerability > But what if www.evil.com has run an injection attack of some kind (SQL, > XSS in blog comments, etc, etc) against www.stupid.com? > > Visitors to stupid.com then suffer a DoS... In such a case, the attacker may just as well clobber body.innerHTML, run a while (1) loop, or otherwise logically deny or alter service to visitors without actually exploiting any specific bug - so I do not see any significant benefit to killing this particular tab. Crashing / hanging the entire browser is somewhat different, as it bears some risk of data loss in plausible usage scenarios. Unfortunately, most implementations do very little to prevent cases that were permitted by standards in the first place (things such as "while (1) str += str", "while (1) alert('foo')", looped blocking XMLHttpRequest calls, ridiculously nested XML and other expensive-to-render content, etc) - which makes finding new instances somewhat futile and pointless, and a result, somewhat frowned upon on security mailing lists (ugh). /mz _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists