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]
Date: Sat, 29 May 2010 02:57:35 +0530
From: "John Smith" <at-x@...e.com>
To: "Vladimir '3APA3A' Dubrovin" <3APA3A@...URITY.NNOV.RU>
Cc: "MustLive" <mustlive@...security.com.ua>,
	"Susan Bradley" <sbradcpa@...bell.net>, <bugtraq@...urityfocus.com>
Subject: Re: Re[4]: DoS vulnerabilities in Firefox, Internet Explorer, Chrome, Opera and other browsers

Hi Vladimir,

Thanks for your views.

I was carried away because the author used scripts (in a global script tag) 
in the PoC of the issue in question which made unconditional recursion 
possible.
Without scripts enabled, if iframe's src property is set to itself(?), it is 
parsed upto 1 level (i.e. not recursed). Hence it doesn't affect or DoS the 
latest browsers (the best I can say...).

A few other points:

1. if a links/ads or any other content-syndication provider allow unverified 
javascript to be served, DoS would be the least of the concern (read: it’s 
the breeding ground of XSS exploits)
2. I more than agree that an issue to be classified as a security 
vulnerability if a combination of tags/properties/scripts causes or is 
capable of causing malice in any form while conforming to the standards 
(which isn't the case here).
3. Just to reiterate my earlier post, DoS is more of an annoyance than 
malice. If the issue noted in this context DoS by a form of unconditional 
recursion (or infinite loop) to create 'out of memory' or stack overflow 
sortof situation (though modern uri handlers handle it gracefully) but 
requires a task kill operation on the script engine's host (the browser in 
this context).

Sadly, there're too many known unknowns to the #2 above which involves the 
support of non-standard techniques like Anti-Phishing Working 
Group/SmartScreen filter etc which doesn't attempt to or can be absolutely 
100% fool-proof...

Best Regards,
w

PS: Lets put IE6 out of context, I'm not sure why it is still brought up or 
why it's still used, because it’s a browser from the times when the first 
ancestor of Firefox (Phoenix) didn't exist. Yes, its that ancient! :)


--------------------------------------------------
From: "Vladimir '3APA3A' Dubrovin" <3APA3A@...URITY.NNOV.RU>
Sent: Saturday, May 29, 2010 2:05 AM
To: "John Smith" <at-x@...e.com>
Cc: "MustLive" <mustlive@...security.com.ua>; "Susan Bradley" 
<sbradcpa@...bell.net>; <bugtraq@...urityfocus.com>
Subject: Re[4]: DoS vulnerabilities in Firefox, Internet Explorer, Chrome, 
Opera and other browsers

> Dear John Smith,
>
> In  general  case  we  are  discussing,  DoS may be caused by e.g. some
> combination of allowed tags/properties or by malformed image.
>
> As  it  was  pointed  by  author,  this  attack  may  be performed with
> scripting  disabled  (with [iframe src=]). That's why e-mail vector may
> be significant.
>
>
> --Friday, May 28, 2010, 11:55:28 PM, you wrote to 3APA3A@...URITY.NNOV.RU:
>
> JS> Point taken. But that'd be a non-issue on the browser's end as much as
> JS> site's that is allowing the rogue scripts (or malformed ads, as per 
> your
> JS> example).
> JS> The fork of this mail thread clearly explains what I'm talking about. 
> The
> JS> issue noted there is a simple DoS attack which every programming 
> language
> JS> and platform is vulnerable too. Its called the "infinite loop". It is 
> not a
> JS> 'security vulnerability' by itself and is completely agnostic of the 
> uri
> JS> handler (try http or anything instead of nntp).
>
> JS> Here's the simplified JS version of it (lets call it the Universal 
> DoS --
> JS> yes, it'd work for every browser on the planet that can execute JS) -
>
> JS> <script>
> JS> while(1)alert('hello world');
> JS> </script>
>
> JS> Done!
>
> JS> Workaround:
> JS> None very intuitive. Maybe allow the user to terminate the script at 
> every
> JS> iteration? specific time period? etc...
>
> JS> --------------------------------------------------
> JS> From: "Vladimir '3APA3A' Dubrovin" <3APA3A@...URITY.NNOV.RU>
> JS> Sent: Friday, May 28, 2010 11:47 PM
> JS> To: "John Smith" <at-x@...e.com>
> JS> Cc: "MustLive" <mustlive@...security.com.ua>; "Susan Bradley"
> JS> <sbradcpa@...bell.net>; <bugtraq@...urityfocus.com>
> JS> Subject: Re[2]: DoS vulnerabilities in Firefox, Internet Explorer, 
> Chrome,
> JS> Opera and other browsers
>
>>> Dear John Smith,
>>>
>>> Actually,  browser DoS may be quite serious vulnerability, depending on
>>> nature  of  DoS.  Think  about e.g. banner or content exchange network,
>>> social  networks,  web  boards,  etc where browser vulnerability may be
>>> used  against  site  or  page because it will harm any visitors of this
>>> site or page.
>>>
>>> In  case  of  this  very vulnerability, most serious impact may be from
>>> e-mail vector.
>>>
>>> --Friday, May 28, 2010, 7:07:50 PM, you wrote to
>>> mustlive@...security.com.ua:
>>>
>>> JS> Just a few cents - DoS in webbrowsers doesn't fall under the 
>>> category
>>> of
>>> JS> "vulnerabilities" rather more of "annoyances". Although I don't deny
>>> the
>>> JS> fact that certain DoS attacks *may lead* or *may serve as hints* to
>>> other
>>> JS> more serious exploits, but that's a different topic and with ASLR in
>>> the
>>> JS> scene, a very grey area of discussion.
>>>
>>>
>>>
>>> -- 
>>> Skype: Vladimir.Dubrovin
>>> ~/ZARAZA http://securityvulns.com/
>>> Стреляя во второй раз, он искалечил постороннего. Посторонним был я.
>>> (Твен)
>>>
>>>
>
>
> -- 
> Skype: Vladimir.Dubrovin
> ~/ZARAZA http://securityvulns.com/
> Машина оказалась способной к единственному действию,
> а именно умножению 2x2, да и то при этом ошибаясь. (Лем)
>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ