|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #59247 Fails to open zip when the central directory entries are in unexpected place
Submitted: 2010-06-01 19:54 UTC Modified: 2015-05-05 14:27 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: andrew at bramp dot freeserve dot co dot uk Assigned: cmb (profile)
Status: Closed Package: zip (PECL)
PHP Version: 5.3.2 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: andrew at bramp dot freeserve dot co dot uk
New email:
PHP Version: OS:


 [2010-06-01 19:54 UTC] andrew at bramp dot freeserve dot co dot uk
All zip files are made up of multiple records, two of these 
being the central directory entries and the end of central 
directory (EOCD). The EOCD contains a offset to the first 
central directory entry, as well as the size of all the 
central directory entries. The problem is that the code does 
not use the offset, and instead assumes the central 
directory entry is immediately before the EOCD. This causes 
the zip to not be parsed correctly and thus unusable.

The occurred when I needed to parse a 2GB zip file which I 
found had unused Zip64 records between the central directory 
and the EOCD.

I have written a patch, and talked about this on the 
official libzip mailing.

I'd appreciate if you apply this patch to the PHP source, as 
I encountered this problem via PHP. I will of course try and 
get this merged upstream.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-01 20:41 UTC] pierre dot php at gmail dot com
Can you send me a patch against php's 5.3 ext/zip as well as a test case pls (zip+script)?

I can apply it soonish as long as all tests pass.
 [2010-06-04 01:57 UTC] mnm_raps at hotmail dot com
Would you kindly email me the patch at mnm_raps[at]hotmail[dot]com as i require it urgently for my project. I am developing a website that generates some excel files, zips them and asks the user to download the zip file.
 [2010-06-04 04:45 UTC] pierre dot php at gmail dot com
@mnm_raps at hotmail dot com

What prevents you to do that now already? Zip works just fine to create archives, or read them for most of the cases but the one describe in this report.
 [2010-06-04 06:32 UTC] andrew at bramp dot freeserve dot co dot uk
I don't see a way to attach files to this bug report, so 
I've stored the patch here:

Now the test case is a little harder. I encounter this bug 
on a 2GB zip file that I didn't not create, and was created 
by a unknown tool. Unfortunately the 2GB zip contains 
sensitive information and I'm not allowed to make it public. 
I could try and make a new test file by hacking up a zip 
file with a hex editor if it would help?

A test script is simply:
$z = new ZipArchive();
$err = $z->open($filename);
if ($err !== true)
   throw new Exception("Failed to open zip file err $err:" . 

and $err will be ZIPARCHIVE::ER_NOZIP (Not a zip archive).
 [2010-06-04 06:53 UTC] pierre dot php at gmail dot com
Does the tests suite still pass with your patch?
 [2010-06-04 09:38 UTC] andrew at bramp dot freeserve dot co dot uk
Before my patch 13 tests failed, after my patch the same 13 
tests fail, but my code is now able to read both normal and 
the zip files with the extra records.

The tests that failed do not seem to be related to Zip in any 
way, and I have submitted the failed list to the QA team.
 [2010-06-04 09:44 UTC] pierre dot php at gmail dot com
All tests pass here (3 different linux and windows), something is wrong in your settings.

What are the errors?
 [2010-06-04 09:54 UTC] andrew at bramp dot freeserve dot co dot uk
I'm not too concerned about the 13 tests that fail as they 
are unrelated to this bug report, but on my Debian Testing 
Linux using gcc-4.4.real (Debian 4.4.4-1) and revision 
299964 of the SVN URL: the 
following failed:

Bug #45877 (Array key '2147483647' left as string) 
Test DateTime::modify() function : usage variation - Passing 
unexpected values to first argument $modify. 
Bug #50392 date_create_from_format enforces 6 digits for 'u' 
format character [ext/date/tests/bug50392.phpt]
Test date_modify() function : usage variation - Passing 
unexpected values to second argument $format. 
Integer overflow [ext/filter/tests/046.phpt]
Phar: phpinfo display 3 [ext/phar/tests/phpinfo_003.phpt]
realpath_cache_size() and realpath_cache_get() 
Test var_dump() function 
getmxrr() test [ext/standard/tests/network/getmxrr.phpt]
http-stream test [ext/standard/tests/network/http-
Test Blowfish crypt() with invalid rounds 
htmlentities() / html_entity_decode() #8592 - #9002 table 
test [ext/standard/tests/strings/htmlentities17.phpt]

As I said I submitted these failures, but I'm unsure where 
to find what as submitted as that might contain more 
 [2010-06-04 09:58 UTC] pierre dot php at gmail dot com
I mean the Zip tests only, other tests are irrelevant :) So I suppose the zip tests pass with or without your patch, right?
 [2010-06-04 10:03 UTC] andrew at bramp dot freeserve dot co dot uk
Sorry, perhaps I misunderstood you :)

I run "make test", and I assumed that ran everything 
(including zip tests) and as I did not see the word zip 
printed in the failed tests I assumed they were fine.

Is there a way to run just the zip tests?

But if I did run the zip tests, then yes with and without 
the patch I get the same list of failed tests.
 [2010-06-04 10:06 UTC] pierre dot php at gmail dot com
make test TESTS=/home/andrew/php-src/php53/ext/zip/tests should do it.
 [2015-05-05 14:27 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2015-05-05 14:27 UTC]
The issue has been fixed in the meantime. Thanks for the bug
report and the patch.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Jul 20 10:01:29 2024 UTC