This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Thomas.Waldmann
Recipients Thomas.Waldmann
Date 2016-10-20.21:08:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za>
In-reply-to
Content
zipfile.is_zipfile has false positives way too easily.

I just have seen it in practive when a MoinMoin wiki site with a lot of pdf attachments crashed with 500. This was caused by a valid PDF that just happened to contain PK\005\006 somewhere in the middle - this was enough to satisfy is_zipfile() and triggered further processing as a zipfile, which then crashed with IOError (which was not catched in our code, yet).

I have looked into zipfile code: if the usual EOCD structure (with empty comment) is not at EOF, it is suspected that there might be a non-empty comment and ~64K before EOF are searched for the PK\005\006 magic. If it is somewhere there, it is assumed that the file is a zip, without any further validity check.

Attached is a failure demo that works with at least 2.7 and 3.5.

https://en.wikipedia.org/wiki/Zip_(file_format)
History
Date User Action Args
2016-10-20 21:08:49Thomas.Waldmannsetrecipients: + Thomas.Waldmann
2016-10-20 21:08:49Thomas.Waldmannsetmessageid: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za>
2016-10-20 21:08:48Thomas.Waldmannlinkissue28494 messages
2016-10-20 21:08:48Thomas.Waldmanncreate