Last modified: 2014-10-11 13:25:21 UTC
Attempting to upload a specific gif file always fails with the error mentioned in the summary. Steps to reproduce: 1. Download the image http://images.kingdomofloathing.com/itemimages/snakes/12bl.gif 2. Upload file to mediawiki (versions 1.20.2 and 1.21.1 tried) Results: Error displayed: "The file is a corrupt or otherwise unreadable ZIP file. It cannot be properly checked for security." Image is not uploaded. Source filename field reverts to no image selected. Expected Results: Image should be uploaded, with no errors given. Notes: I don't see anything wrong with the image---it's a regular (small) gif image, and not a zip file. There are many other gif images on the site, so it is not a problem with gif files in general, it is specific to this particular file. The message is the textual form of the "zip-bad" error, which is returned by ZipDirectoryReader in a few places. I turned on debug logging, and found the full failure flow: ----------- MimeMagic::__construct: loading mime types from /var/www/wiki/includes/mime.types MimeMagic::__construct: loading mime info from /var/www/wiki/includes/mime.info MimeMagic::doGuessMimeType: analyzing head and tail of /tmp/phpWYS1lh for magic numbers. MimeMagic::doGuessMimeType: getimagesize detected /tmp/phpWYS1lh as image/gif MimeMagic::guessMimeType: guessed mime type of /tmp/phpWYS1lh: image/gif MimeMagic::improveTypeFromExtension: improved mime type for .gif: image/gif FSFile::getProps: /tmp/phpWYS1lh loaded, 1851 bytes, image/gif. mime: <image/gif> extension: <gif> UploadBase::detectScript: checking for embedded scripts and HTML stuff UploadBase::detectScript: no scripts found ZipDirectoryReader: Fatal error: trailing bytes after the end of the file comment ----------- ZipDirectoryReader's complaint is likely true...but only because it is not a zip file. Just to be sure I attempted to unzip the file, and only got errors as expected: ----------- caution: zipfile comment truncated warning [12bl.gif]: zipfile claims to be last disk of a multi-part archive; attempting to process anyway, assuming all parts have been concatenated together in order. Expect "errors" and warnings...true multi-part support doesn't exist yet (coming soon). error [12bl.gif]: missing 6459880350 bytes in zipfile (attempting to process anyway) error [12bl.gif]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) ----------- Loading the image into gimp, doing a dummy-edit and resaving it without a comment or with a different comment does not help.
Well the zip program (that you quoted above) is claiming its a multipart zip file. Its entirely possible to have a file that is both a valid gif file and a valid zip file (so called GIFAR vulnrability). Well I could try checking the gif file in question later to be sure, this does not appear to be a bug at first glance.
I do think it's a bug since it is rejecting a perfectly valid image for an invalid reason. Seems like this problem has been around for a few years too: http://lists.wikimedia.org/pipermail/mediawiki-l/2011-December/038423.html I checked, and the image I am trying to upload also has the magic bye sequence "50 4B 05 06", so that does indeed seem to be the issue. But with arbitrary image data that's bound to happen sometimes! Since unzip itself chokes on it it must be possible to determine that it not a well formed zip file, and thus not something subject to GIFAR (from my naive reading of the less-than-detailed wikipedia article on GIFAR, it would need a valid zipfile to work properly wouldn't it?)
Confirmed; reproducible on test.wikipedia.org. This isnt an exact duplicate of bug 31930, but it very close. Note that this gif file is 1851 bytes, and doesnt include the java bytecode sequence cafebabe, so I am pretty sure it isnt going to be executed by any JVM.
Created attachment 16747 [details] Specific gif tripping the bad-zip check
