| 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: Wed, 04 Mar 2009 12:00:10 +1300 From: Nick FitzGerald <nick@...us-l.demon.co.uk> To: full-disclosure <full-disclosure@...ts.grok.org.uk> Subject: Re: Apple Safari ... DoS Vulnerability Chris Evans to me: > By this definition of yours, DoS is fundamentally built in to browsers > (by way of simply following specifications) -- even those with decent > privsep models. Not necessarily... Factually, probably so but that says more about our s/w development methods and what has (historically) passed as "acceptable" in that arena. Browsers could reasonably implement various kinds of resource expenditure limitations, but few, if any, do OOTB (FF 2.x I think added some basic "this script is taking too long" controls, but there is a lot more that could be done). Is that specification antagonistic? Arguably yes because the specifications don't say "... to N levels of recursion" and such. But maybe that tells us an awful lot about the specifications and the culture of the folk who wrote them? Yep -- they came from that "she'll be right" s/w dev background that is responsible for most of the crap that means we're assured of jobs for life (well, if you're as old as me anyway!). > Web security IS fundamentally broken at the foundations, so I'm not > going to disagree with you. 8-) > It raises the question: DoS is an overloaded term, ... DoS is not an overloaded term -- it means pretty much what it says, as Thierry pointed out. Yes, a lot of noobs and journalists confuse it with _D_DoS and its usual, deliberate "with malicious intent" connotation, but that might just be an education problem... > ... perhaps it should > be reserved for cases that actually have real-world significance? Or > is a new term required? How do we operationally define "real-world significance"? That was my original point -- this is a DoS Whether it's "worthy" of discussion here or not is a different issue that touches precisely on the issue of defining "real-world significance". There may be some subtle use for such a vuln that allows it to be combined with one or more other "minor" vulns to make for a modestly worrying attack, or there may not. Until that is found (probably by a Black Hat because White Hats are so quick to dismiss things like this with "it's only a trivial browser tab-closing DoS" and move on to sexier sounding bugs) this may be ignored because no-one deems it "worthy", extending the long, sad history of quality neglect in s/w development. Regards, Nick FitzGerald _______________________________________________ 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