In-Reply-To: <20040713101632.21299.qmail (at) www.securityfocus (dot) com [email concealed]>

Thanks to SecuriTeam for pointing out that the known path vulnerability does not work. Since I got default.nop, it seemed to me as if this is normal, but actually the last 3 letters are random.

The NULL byte bug on the other hand still remains unpatched and working.

Sorry about that.

- Mindwarper

>Received: (qmail 13607 invoked from network); 13 Jul 2004 15:28:02 -0000

>Received: from outgoing.securityfocus.com (HELO outgoing3.securityfocus.com) (205.206.231.27)

> by mail.securityfocus.com with SMTP; 13 Jul 2004 15:28:02 -0000

>Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])

> by outgoing3.securityfocus.com (Postfix) with QMQP

> id 38653236F94; Tue, 13 Jul 2004 09:27:45 -0600 (MDT)

>Mailing-List: contact bugtraq-help (at) securityfocus (dot) com [email concealed]; run by ezmlm

>Precedence: bulk

>List-Id: <bugtraq.list-id.securityfocus.com>

>List-Post: <mailto:bugtraq (at) securityfocus (dot) com [email concealed]>

>List-Help: <mailto:bugtraq-help (at) securityfocus (dot) com [email concealed]>

>List-Unsubscribe: <mailto:bugtraq-unsubscribe (at) securityfocus (dot) com [email concealed]>

>List-Subscribe: <mailto:bugtraq-subscribe (at) securityfocus (dot) com [email concealed]>

>Delivered-To: mailing list bugtraq (at) securityfocus (dot) com [email concealed]

>Delivered-To: moderator for bugtraq (at) securityfocus (dot) com [email concealed]

>Received: (qmail 21210 invoked from network); 13 Jul 2004 04:13:43 -0000

>Date: 13 Jul 2004 10:16:32 -0000

>Message-ID: <20040713101632.21299.qmail (at) www.securityfocus (dot) com [email concealed]>

>Content-Type: text/plain

>Content-Disposition: inline

>Content-Transfer-Encoding: binary

>MIME-Version: 1.0

>X-Mailer: MIME-tools 5.411 (Entity 5.404)

>From: Mind Warper <mindwarper (at) linuxmail (dot) org [email concealed]>

>To: bugtraq (at) securityfocus (dot) com [email concealed]

>Subject: Two Vulnerabilities in Mozilla may lead to remote compromise

>

>

>

>Two Vulnerabilities in Mozilla may lead to remote compromise.

>=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=

>

>----------------------

>Vendor Information:

>----------------------

>

>Homepage : http://www.mozilla.org

>Vendor : informed on 11/06/04

>Mailed advisory: 13/06/04

>Vender Response : None yet

>

>

>----------------------

>Affected Versions:

>----------------------

>

>All version of Mozilla and Firefox

>

>----------------------

>Description:

>----------------------

>

>There are two vulnerabilities in Mozilla that may lead to remote code execution under local zone.

>The first vulnerability affects firefox, and may affect mozilla as well. I have only tested

>firefox under windows 2000 and windows XP so I'm not sure if this issue exists on other OS's.

>The problem is that firefox stores its cache in a known directory, and some of the cached html

>is stored in known files. If a victim visits the attackers website which includes malicious javascript

>and then views the content of one of the cache files in local zone, the script will get executed and

>the attacker will be able to compromise the victim's system. This vulnerability in mozilla can't be

>abused as it is, but combined with a few other vulnerabilities the attacker could execute malicious

>code on the victim's computer without having the victim do anything except visit his website (very

>similar to the exploits in Internet Explorer).

>

>The second vulnerability allows the attacker to modify the mime type by using the infamous NULL byte.

>Mozilla by default uses the file extention name to decide how to show a local file. For example,

>if a user requests file:///C:/blah.txt, Mozilla will show the contents of blah.txt, but if the user

>requests file:///C:/blah then Mozilla will pop up a window asking the user if he/she wants to download

>the file. By adding a NULL byte at the end of the filename, and the extention that you want Mozilla

>to handle right after the filename, you can make Mozilla open file:///C:/blah as an html file.

>Just like the vulnerability above, this can't be used alone to execute malicious code, the attacker

>needs to combine the above vulnerability with this one to succeed.

>

>Since the known cache file names have no extention by default on windows, if the attacker uses the NULL

>byte bug, he/she can cause mozilla to show the contents of one of the cache files as an html file,

>and therefore cause mozilla to execute whatever scripts that exist in the cache files.

>

>

>----------------------

>Exploit:

>----------------------

>

>The first vulnerability does not require an exploit.

>On windows 2000, there are 3 cache files with known names. They are:

>

>1. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_CACHE_001_

> [ This cache file stores the http headers ]

>

>2. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_CACHE_002_

>3. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_CACHE_003_

> [ These 2 cache files store the html data ]

>

>If we combine both vulnerabilities shown above we get something like this:

>

>file://C:\\Documents and Settings\\Administrator\\Application Data\\Mozilla\\Firefox\\Profiles\\default.nop\\Cache\\_CACHE_002_%00.htm
l

>

>Mozilla will open this file without the %00.html, but it will treat it as an html file and won't pop up a download window.

>

>

>----------------------

>Solution:

>----------------------

>

>Visit mozilla.org to check for updates.

>

>----------------------

>Contact:

>----------------------

>

>- Mindwarper

>- mindwarper (at) mlsecurity (dot) com [email concealed]

>- http://mlsecurity.com

>

[ reply ]