| New User, Welcome! Login |
Next Page >>
browsers
to contacts?
MustLive wrote:
> Hello Susan!
>
>> Granted I can denial of service a browser just by loading up a horrible
>> add in or just using a browser
>
> DoS of the browser is already bad thing. And there are many risks for
> users
> from DoS holes in browsers, which I wrote about in 2008 in my articles
Hello Susan!
> Granted I can denial of service a browser just by loading up a horrible
> add in or just using a browser
DoS of the browser is already bad thing. And there are many risks for users
from DoS holes in browsers, which I wrote about in 2008 in my articles
Dangers of DoS attacks on browsers and Dangers of resources consumption DoS
attacks. But mostly browser developers ignore to fix these issues.
Just a few cents - DoS in webbrowsers doesn't fall under the category of
"vulnerabilities" rather more of "annoyances". Although I don't deny the
fact that certain DoS attacks *may lead* or *may serve as hints* to other
more serious exploits, but that's a different topic and with ASLR in the
scene, a very grey area of discussion.
Case in point: XSS can be of various kinds and most of them (I'm talking of
about 99.99%) can be attributed to the design of the web
technologies/protocols specifications (http, ajax, etc etc...you name it)
and the browsers can only do that much. Hence its not feasible for a
particular case.
Taking into account that 3 from 4 vendors answered me (except Microsoft) and
Google had already non affected Chrome 4, and Mozilla and Opera promised to
fix it (we'll see when and how they do it), then you can see that my
approach works. And responsible full disclosure can force browser vendors to
attend more at security of their software.
Soon I'll write to security mailing lists about new vulnerabilities in
different browsers. And you can not worry about that - in those advisories
I'll use a littler different approach of informing browser vendors. You will
to give additional explanations. Also I'll point on some important things
for all readers of the list.
First of all, readers of both Bugtraq and Full-disclosure must understand,
that if you had no questions to my first advisory (from this series of
advisories (I posted three already) of vulnerabilities in browsers,
which belong to group of DoS via protocol handlers), then there must be no
questions for next advisories. Otherwise it'll be double standards (not
moaning on 1st advisory and moaning on 2nd and 3rd ones) and as I already
wrote to the lists, double standards are bad and better to not use them.
The following PoC code is available:
http://[host]/contract_add_service.php?contractid=1%20union%20%28select%20min%28@a:=1%29from%20%28select%201%20union%20select%202%29k%20group%20by%20%28select%20concat%28@@version,0x0,@a:=%28@a%2B1%29%2%29%29%29%20+--+
3) Input passed via the "mode" GET parameter to contact_support.php is not properly sanitised before being returned to the user.
This can be exploited to execute arbitrary HTML and script code in a user browser session in context of affected website.
The following PoC code is available:
http://[host]/contact_support.php?mode=1%22%3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
necessity and definitely not a URI (of any kind) exploit or a security
vulnerability.
Some last specifics (mostly reiterating what I said in my earlier posts) -
1. You can take this issue up with the content aggregators (CDN etc) and or
website programmers, this is not an issue to be addressed by the webbrowsers
because the solution of it remains imperfect in theory (one of my posts have
a 'workaround'...maybe a 'good to have' feature which WILL open up another
can of worms...).
2. Now the even vague non-scripted issue which you insist upon - If you are
trying to say that a 1000 lines of <iframe src='nntp:something'/> (which is
I want to warn you about Denial of Service vulnerabilities in Firefox,
Internet Explorer, Chrome and Opera. Which belong to type of DoS via
protocol handlers. Earlier I already wrote about DoS vulnerabilities in
Firefox, Internet Explorer, Chrome and Opera and DoS attacks on email
clients via protocol handlers. This new advisory will show you the situation
of browsers behavior with other protocol handlers.
All those who doubt that these DoS vulnerabilities in browsers and email
clients are security vulnerabilities, must read my first advisory on this
topic (http://www.securityfocus.com/archive/1/511327/30/0/threaded). Where I
mentioned about Mozilla's MFSA 2010-23
Hello Susan and other readers, who replied to my previous advisory.
Earlier I've already answered Vladimir, now I'd answer Susan and soon I'd
answer John. But now one important note to every reader of the list,
including John Smith. Which I already wrote about 1,5 week ago (after
posting of a first advisory about DoS in browsers) to one reader of
Full-disclosure who inattentively read that advisory (he missed message
about attacking without JS) and also to Mozilla (who became discussing this
issue and only drew attention to attacking with JS vector). That, as I wrote
in both advisories, this attack via iframes can also be conducted without
JavaScript. So even turning JS off will not help.
1) Input passed to the "clientid" parameter in "www/admin/banner-
acl.php", "www/admin/banner-edit.php", "www/admin/campaign-zone.php",
"www/admin/advertiser-campaigns.php", "www/admin/campaign-
banners.php", and "www/admin/banner-activate.php" is not properly
sanitised before being returned to the user. This can be exploited to
execute arbitrary HTML and script code in a user's browser session in
the context of an affected site.
2) Input passed to the "orderdirection" and "listorder" parameters in
"www/admin/userlog-index.php" and "www/admin/stats.php" is not
properly sanitised before being returned to the user. This can be
#
#This code has been released Only for educational purposes. The author
cannot be held responsible for any bad use.
# Usage:
# 1) perl fortiGuard.pl
# 2) Configure your browser's proxy at localhost:5050
# 3) Have fun.
# --- Start Of Script---
use strict;
=============================================================
Android Browser Cross-Application Scripting (CVE-2011-2357)
=============================================================
1) Background
--------------
Android applications are executed in a sandbox environment, to ensure that no
application can access sensitive information held by another, without adequate
privileges. For example, Android's browser application holds sensitive
information such as cookies, cache and history, and this cannot be accessed by
Hello Thierry!
About your "bug to rule them all" I can tell, that it's interesting
vulnerability and interesting research itself. I have found DoS
vulnerabilities in multiple browsers many time, but I never tested in such
many browsers and systems. So you made a large research (with help of those
people who helped you with testing in different systems) - this DoS hole
exists (or existed) in so many systems: different desktop browsers, email
clients, browsers for mobile devices, game devices and possible other
devices with support of JavaScript.
For complete post with images, please visit
http://securethoughts.com/2009/11/using-blended-browser-threats-involving-ch
rome-to-steal-files-on-your-computer/
SECURETHOUGHTS.COM ADVISORY
=============================================
- CVE-ID : CVE-2009-XXXX (Chrome) {Pending}
- Release Date : November 05, 2009
- Severity : Medium
- Discovered by : Inferno
Found on the 16th
Blogged on the 17th
Told vendors on the 18th
Posted here on the 18th
Granted I can denial of service a browser just by loading up a horrible
add in or just using a browser, but as a customer of each of these
vendors, can I respectfully ask that you give vendors time to respond
before posting? These vendors do not ignore security issues and do
respond (unlike some of the web sites with the captcha issues) So why
haven't you given them that opportunity?
CVE Name: CVE-2009-1140
3. *Vulnerability Description*
Internet Explorer (IE) is the most widely used Web browser, with an
estimated count of 1,100 million users according to a worldwide survey
conducted and published in 2008 [1]. This advisory describes a
vulnerability that provides access to the contents of any file stored in
the local filesystem of user's machines running vulnerable versions of IE.
Bil,
> > If the browser displayed the file
> > and the user takes no precautions, the file should
> > be in the browser's cache.
>
> Yngve Pettersen of Opera is working on a proposed
> browser specification for "Context Cache" that
> would allow cached items to expire/be discarded
> immediately upon logging out:
It's not immediately obvious that this error is still exploitable, simple
tricks like <img src=bad onerror=code> don't apply, and <script>code</script>
isn't helpful as the code isn't evaluated again. In situations like this, the
best course of action is to harass lcamtuf until he gives you the solution,
which of course his encyclopaedic knowledge of browser security quirks produced
immediately.
<script defer>code</script>
The defer property is an IE-ism which solves the problem, documented by
>
> It's not immediately obvious that this error is still exploitable, simple
> tricks like <img src=bad onerror=code> don't apply, and <script>code</script>
> isn't helpful as the code isn't evaluated again. In situations like this, the
> best course of action is to harass lcamtuf until he gives you the solution,
> which of course his encyclopaedic knowledge of browser security quirks produced
> immediately.
>
> <script defer>code</script>
>
> The defer property is an IE-ism which solves the problem, documented by
It's not immediately obvious that this error is still exploitable, simple
tricks like <img src=bad onerror=code> don't apply, and <script>code</script>
isn't helpful as the code isn't evaluated again. In situations like this, the
best course of action is to harass lcamtuf until he gives you the solution,
which of course his encyclopaedic knowledge of browser security quirks produced
immediately.
<script defer>code</script>
The defer property is an IE-ism which solves the problem, documented by
====================================================
Security Research Advisory
Vulnerability name: Nokia Browser Array Sort Denial Of Service Vulnerability
Advisory number: LC-2008-04
Advisory URL: http://www.ikkisoft.com
====================================================
1) Affected Software
Hello Bugtraq!
I want to warn you about Cross-Site Scripting vulnerability in Mozilla
Firefox, Opera and other browsers. It allows to bypass protection from
executing of JavaScript code in location-header redirectors (by redirecting
to javascript: URI).
Recently, 04.08.2010, I wrote about vulnerability in Mozilla and Mozilla
Firefox at my site. I made full disclosure because Mozilla completely
ignored similar vulnerability, which I informed them in August 2009, like
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
class of web exploits originally coined cross-protocol scripting, but now more
commonly referred to as inter-protocol exploitation.
Goatse Security has a double feature for you, starting with a 0day vuln:
* Safari (and other webkit-based)browser port blocking bypassed by integer overflow
and a technique that, as far as I know, has not been premiered before:
* XHR (XMLHttpRequest) as a vector for mail merging or wordlist attacks in
XPS/IPE attacks
handling of multipart/x-mixed-replace images. Although no exploit was
shown, re-use of freed memory has led to exploitable vulnerabilities
in the past (CVE-2010-0164).
Mozilla developers identified and fixed several stability bugs in the
browser engine used in Firefox and other Mozilla-based products. Some
of these crashes showed evidence of memory corruption under certain
circumstances and we presume that with enough effort at least some
of these could be exploited to run arbitrary code (CVE-2010-0165,
CVE-2010-0167).
Hello Bugtraq!
I want to warn you about File Download and Denial of Service vulnerabilities
in Mozilla Firefox, Internet Explorer, Google Chrome and Opera. Earlier I
already wrote about DoS vulnerabilities in different browsers via different
protocol handlers. And now I'll tell about research concerned with attacks
via protocols http and ftp which I made already in 2008 and published at
30.06.2010.
-----------------------------
handling of multipart/x-mixed-replace images. Although no exploit was
shown, re-use of freed memory has led to exploitable vulnerabilities
in the past (CVE-2010-0164).
Mozilla developers identified and fixed several stability bugs in the
browser engine used in Firefox and other Mozilla-based products. Some
of these crashes showed evidence of memory corruption under certain
circumstances and we presume that with enough effort at least some
of these could be exploited to run arbitrary code (CVE-2010-0165,
CVE-2010-0167).
Back in 2006, there was interesting research done by James Holderness[1] and
James M. Snell[2] which uncovered a variety of XSS issues in various online
feed aggregator services (e.g. Feed Demon). The vulnerability arises from
the fact that it is not expected of RSS readers to render scripted content.
I want to extend that research by doing threat analysis on inbuilt feed
readers offered in most modern browsers. I have found Google Chrome (v2,3)
and Opera (v9,v10) to be vulnerable, while Internet Explorer(v7,8), Firefox
3.5 and Safari 4 are resilient to the exploits mentioned below.
IV. DESCRIPTION
-------------------------
possible. You are set.
Has this been done before ? Yes, take google chrome as an example.
In Google chrome, tabs are separated in such a way that well, only
the tab affected closes, not the whole browser not
the complete OS. So this is mitigating all these bugs by design and
reducing the impact to a minimum, to a degree where I agree that it
could be ignored and not called a "vulnerability".
If someone designs software and claims that these problems cannot be mitigated
Dear all,
with research colleague Thomas Duebendorfer from Google in Zurich I've
finally had a chance to look deeper into the performance of Web
browser update mechanisms. The analysis of anonymized Google Web
server logs allowed us to compare and rank the update strategies
deployed by
Google Chrome, Mozilla Firefox, Apple Safari, and Opera. We found
considerable differences in the performance of the update techniques
deployed by each browser by measuring the share of the latest minor
Next Page>>
|
|
|
