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] [day] [month] [year] [list]
Date: Tue, 8 Sep 2009 23:58:07 +0300
From: "MustLive" <mustlive@...security.com.ua>
To: <advisories@...ern0t.net>
Cc: <bugtraq@...urityfocus.com>
Subject: Re: DoS vulnerability in Google Chrome

Hello MaXe!

> However, I just tested the vulnerability in chrome and the incidents were
> different.

As I said on my system it's solely Chrome DoS vulnerability. On my system
with Firefox 3.0.13 (and previous versions, when I tested them before) there
is not such issue, when Firefox was DoSed via Chrome, i.e. Cross-Application
DoS. Taking into account that you have this issue with Firefox 3.5.2, than
it can be problem with FF 3.5.x versions, which have tight integration with
Chrome's and other software's URI handlers.

> However I believe this can be used / triggered against any other
> application installed that FireFox knows exists on the target operating
> system. :-)

It's quite possible, because I didn't check this Cross-Application DoS in
Fifefox (due to that my FF 3.0.13 is not affected to this attack). If there
is such hole, it can be possible to make similar attack against any other
installed application which have their URI handler registered in the system.
And not only Firefox (and the system) must know about it, but the attacker
also must know about it :-).

My idea was to made blocking DoS attack on Chrome (first exploit was
blocking DoS, second was blocking DoS and DoS via resources consumption).
Which I wrote about last year in my Classification of DoS vulnerabilities in
browsers (http://websecurity.com.ua/2550/). In 2008 I wrote about many
blocking DoS vulnerabilities in browsers, and this year I continued to write
about such holes, and after this one I'd write about another one soon (which
I found last year). Like these DoS vulnerabilities in Firefox, IE, Chrome
and Opera (http://websecurity.com.ua/3194/). Or like DoS vulnerability in
Internet Explorer 7 (http://websecurity.com.ua/2872/), which is similar to
DoS vulnerabilities in Firefox, Opera and Chrome
(http://websecurity.com.ua/2456/), all of them are printing DoS attacks.

> This will ONLY work if FireFox does NOT know which program to use.

It's interesting, because as I understand from your first information that
if works in Firefox (via Chrome) and from your previous text ("that FireFox
knows exists on the target operating system"), it must work if Firefox does
KNOW about which program to use. But in your case DoS effect is better when
Firefox does not know about program, then if it does know.

> (I'll post it on my own website anyway, giving you credit too of course.)

Thanks. I'm glad that my blocking DoS and DoS via resources consumption
exploit give you inspiration to find new way to attack Firefox and IE7 ;-).

> Internet Explorer 7 version: 7.0.5730.13 will by the way consume up to 70%
> of the CPU if the same script is run.

MaXe, it's resource consumption DoS, which described in my mentioned-above
Classification of DoS vulnerabilities in browsers. So 70% or higher (up to
100%) CPU resources is used, it's already resource consumption DoS.

As I wrote before, my IE6 isn't affected by that hole in Chrome. Does your
IE7 is affected by my Chrome exploit, or only by your AIM exploit? Because
if there is mentioned hole, then it must be affected by both exploits.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: <advisories@...ern0t.net>
To: <bugtraq@...urityfocus.com>; <mustlive@...security.com.ua>
Sent: Wednesday, August 26, 2009 11:41 AM
Subject: Re: DoS vulnerability in Google Chrome


Hello MustLive,


Thanks for your immediate reply.

I have now tested what you said, cause I suspected that it was only
happening because Google Chrome was installed, due to FireFox isn't able to
know what ``chromehtml:ยดยด is on its own. (it has to be associated with an
application in this case).

The following would open a lot of windows, consuming most likely all
ressources:
http://websecurity.com.ua/uploads/2009/Google%20Chrome%20DoS%20Exploit2.html

FireFox version: FireFox 3.5.2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; da;
rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Google Chrome versions: 4.0.202.0 && 2.0.172.43 (both tested, the first is
the new beta.)

Operating System: Windows XP Pro SP2
Hardware: 1.8ghz (single core) & 1GB ram.

However, I just tested the vulnerability in chrome and the incidents were
different. In Google Chrome it appears to perform a deadlock of the browser
while on FireFox it performs a starvation "attack" by opening a huge amount
of windows and thereby eventually "killing" all the ram making Windows
completely useless (almost).

The only thing I could do was to logout and then log back in. Task Manager
was unable to help me even though it was set to "Always On Top". If the Task
Manager was opened first then I might have had a chance but if it weren't
then 4 out of 5 times the best option would be to logout and then re-login.

I believe this is a kind of functionality bug versus denial of service bug
in FireFox which unfortunately is not related to the Chrome Bug.

This was tested at my work since I don't have Google chrome installed on my
linux installation at home. However I believe this can be used / triggered
against any other application installed that FireFox knows exists on the
target operating system. :-)

F.ex. I just tested your script, but with a small modification:
<script>
function DoS() {
document.location="aim:goim?lol";
setTimeout(DoS,1);
}
</script>
<body onLoad="DoS()">

Which made FireFox consume from 100mb ram to 250mb in less than 5-7 seconds.
(I havent' been able to check how much more ressources it might consume if i
ran it longer, but it would render my Windows installation at work useless).
This will ONLY work if FireFox does NOT know which program to use.
If FireFox knows the application and thereby wont ask, then the above script
would only consume 15-25% of the CPU ressources, but no extra ram.

I'm sorry if this has already been reported for FireFox, I just stumbled
over it.

If someone decides to make this a DoS vulnerability then I believe some
credit (to me) is in order ;-) (I'll post it on my own website anyway,
giving you credit too of course.)

Internet Explorer 7 version: 7.0.5730.13 will by the way consume up to 70%
of the CPU if the same script is run. However it will not trigger a DoS
condition in IE nor Windows, except if you might have a lot of other heavy
programs running.



Best regards,
MaXe - Founder of InterN0T
http://www.intern0t.net



Hello MaXe!

Thanks for information.

It's interesting why your Firefox 3.5.2 is vulnerable, because on my
computer only Chrome was vulnerable, and not Firefox 3.0.13 and other
browsers (Mozilla, IE6 and Opera). Yes, I have Chrome installed on the same
system and it does not affect other browsers (not in case of this DoS hole,
not in case of other holes which I found).

Besides, which exploit works in Firefox 3.5.2 in your case? Maybe it's hole
in Firefox 3.5.x. Then it'll be better for you to check it on the system
with Firefox, but without Chrome. In case if it's Cross-Application DoS
(http://websecurity.com.ua/2600/, which you can read on English
http://translate.google.com/translate?hl=en&ie=UTF-8&u=http://websecurity.com.ua
/2600/&sl=uk&tl=en),
and Firefox 3.5.2 is affected via Chrome (you must test it by running
exploit in Firefox 3.5.2 on systems with and without Chrome installed), then
there are things which we need to know. Which browsers (Firefox 3.5.x and
others) are affected, and which versions of Chrome lead to this issue.

Besides, as I was informed recently, Google Chrome 1.0.154.65 is also
vulnerable.

P.S.

Different people have different signatures ;-). It's like: show me your
signature and I'll tell you who you are.

Best wishes & regards,
Eugene Dokukin aka MustLive
Security auditor and security researcher
http://websecurity.com.ua

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ