full-disclosure - Re: Apple Safari ... DoS Vulnerability

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <72daeffd0903031609t89fb8f8yddd9c44f3899514e@mail.gmail.com>
Date: Tue, 3 Mar 2009 16:09:53 -0800
From: Chris Evans <scarybeasts@...il.com>
To: nick@...us-l.demon.co.uk
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Apple Safari ... DoS Vulnerability

On Tue, Mar 3, 2009 at 3:00 PM, Nick FitzGerald
<nick@...us-l.demon.co.uk> wrote:
> 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".

Let me put it another way.
You have lame, lame tab crashing bugs being released and labelled as a
"DoS" we should all get excited about. Failure to shoot down this
behaviour will only lead to it propagating. I'd love to see a little
less idealism and a little more pragmatism.

Cheers
Chris

>
> 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/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/