Full Disclosure mailing list archives
Re: Apple Safari ... DoS Vulnerability
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Wed, 04 Mar 2009 12:00:10 +1300
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/
Current thread:
- Re: Apple Safari ... DoS Vulnerability nzerozero p (Mar 01)
- <Possible follow-ups>
- Re: Apple Safari ... DoS Vulnerability Chris Evans (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Nick FitzGerald (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Chris Evans (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Nick FitzGerald (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Michal Zalewski (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Valdis . Kletnieks (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Nick FitzGerald (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Michal Zalewski (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Nick FitzGerald (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Chris Evans (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Nick FitzGerald (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Stuart Dunkeld (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Chris Evans (Mar 03)
- Re: Apple Safari ... DoS Vulnerability Chris Evans (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Pavel Kankovsky (Mar 04)
- Re: Apple Safari ... DoS Vulnerability Nick FitzGerald (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Valdis' Mustache (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Jason Starks (Mar 02)
- Re: Apple Safari ... DoS Vulnerability Valdis' Mustache (Mar 02)