Bekijk Volledige Versie : Two Vulnerabilities in Mozilla may lead to remote compromise
Mind Warper
13/07/04, 17:55
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\_C ACHE_001_
[ This cache file stores the http headers ]
2. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_002_
3. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_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\\Cac he\\_CACHE_002_%00.html
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@mlsecurity.com
- http://mlsecurity.com
In-Reply-To: <20040713101632.21299.qmail@www.securityfocus.com>
Re: Vulnerability No. 1: Mozilla stores cache data in directory with random name, so it definitely isn´t vulnerable
(the directory is %appdata%\Mozilla\Profiles\_name_of_profile_\_rand om_name_\Cache )
Re: Vulnerability No. 2:
Both Mozilla and Firefox are vulnerable. Tested versions: 1.7.1 (Mozilla), 0.9 (Firefox) running on Windows 2000/XP.
BTW, the file can be without any extension, but also with arbitrary extension, so for example file:///C:/blah.txt%.mp3 also works.
Phil
>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@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>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@www.securityfocus.com>
>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@linuxmail.org>
>To: bugtraq@securityfocus.com
>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\_C ACHE_001_
> [ This cache file stores the http headers ]
>
>2. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_002_
>3. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_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\\Cac he\\_CACHE_002_%00.html
>
>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@mlsecurity.com
>- http://mlsecurity.com
>
Daniel Veditz
14/07/04, 00:55
Mind Warper wrote:
> Vendor : informed on 11/06/04
> Mailed advisory: 13/06/04
In the future please send notification to security at mozila.org. The only
thing we could find was a bug filed two days ago.
> There are two vulnerabilities in Mozilla that may lead to remote code execution under local zone.
Mozilla does not have a local zone.
> The problem is that firefox stores its cache in a known directory,
It does not, each user's profile directory is unique. Upon receiving this
we're reconsidering whether three bytes of randomness is sufficient, but in
any case it isn't trivial as you suggest. (Also the "Administrator" part of
the path will differ depending on the windows login name, but an attacker
could stick with "Owner" and get 99% of all WinXP Home users.)
> The second vulnerability allows the attacker to modify the mime type by using the infamous NULL byte.
This is clearly a bug, thank you. From our brief look this morning we're not
convinced it's exploitable, but it's troubling and we'll fix it.
> 2. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_002_
> 3. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_003_
> [ These 2 cache files store the html data ]
Those files will have pieces of different documents. If it contains just
your planted file that would be quite a coincidence.
-Dan Veditz
Mozilla Security Group
>All version of Mozilla and Firefox
I was under the impression that mozilla firefox disallowed access to local
files (not sure about mozilla but I assume it's the same)
When I link to a local file from the internet, I get a
Security Error: Content at http:///.... May not load or link to
File:/// ...
Message in the javascript console. Have you got a demo you can show us?
-----Original Message-----
From: Mind Warper [mailto:mindwarper@linuxmail.org]
Sent: dinsdag 13 juli 2004 12:17
To: bugtraq@securityfocus.com
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\_C ACHE_001_
[ This cache file stores the http headers ]
2. C:\Documents and Settings\Administrator\Application
Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_002_
3. C:\Documents and Settings\Administrator\Application
Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_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\\Cac he\\_CACHE_002_%00.html
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@mlsecurity.com
- http://mlsecurity.com
Mind Warper
14/07/04, 08:55
In-Reply-To: <20040713101632.21299.qmail@www.securityfocus.com>
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@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>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@www.securityfocus.com>
>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@linuxmail.org>
>To: bugtraq@securityfocus.com
>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\_C ACHE_001_
> [ This cache file stores the http headers ]
>
>2. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_002_
>3. C:\Documents and Settings\Administrator\Application Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_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\\Cac he\\_CACHE_002_%00.html
>
>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@mlsecurity.com
>- http://mlsecurity.com
>
Darren Pilgrim
14/07/04, 14:25
> From: Mind Warper [mailto:mindwarper@linuxmail.org]
>
> 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.
Within the limitations of the security settings for the browser. If you
have Java/JS disabled, the attack won't work.
> 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\_C ACHE_001_
> [ This cache file stores the http headers ]
>
> 2. C:\Documents and Settings\Administrator\Application
> Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_002_
> 3. C:\Documents and Settings\Administrator\Application
> Data\Mozilla\Firefox\Profiles\default.nop\Cache\_C ACHE_003_
> [ These 2 cache files store the html data ]
The profile folder isn't consistent. The default folder created during the
install has an extension that changes. On my machine, for example, the
folder created was default.cuo. If you set up additional profiles, the
default folder name is "Default User" and you can change it from within the
profile creation wizard. You also have to know the Windows username to
create the path.
While the above does work if you change the path to match your
configuration, the _CACHE_002_ and _CACHE_003_ files don't contain complete
copies of the HTML files, so it's not guaranteed that a malicious script
would be there. The actual cache files are named with non-sequential,
32-bit numbers.
Pavel Kankovsky
16/07/04, 00:25
On Tue, 13 Jul 2004, Jelmer wrote:
> I was under the impression that mozilla firefox disallowed access to local
> files (not sure about mozilla but I assume it's the same)
>
> When I link to a local file from the internet, I get a
> Security Error: Content at http:///.... May not load or link to
> File:/// ...
This behaviour depends on security.checkloaduri. True, the default value,
disallows links from http: et al to file:
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."