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.

Unsupported provider

classification
Title: zipfile - ZipExtFile.read goes into 100% CPU infinite loop on maliciously binary edited zips
Type: security Stage: resolved
Components: IO, Library (Lib) Versions: Python 3.3, Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: cvrebert, nandiya, python-dev, ronaldoussoren, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2013-12-27 02:11 by nandiya, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
malzip.py nandiya, 2013-12-27 02:11 A python script which creates the maliciously crafted zip and demonstrates hang (python3.3)
zipfile_eof.patch serhiy.storchaka, 2014-01-04 20:37 review
Messages (5)
msg206978 - (view) Author: Nandiya (nandiya) Date: 2013-12-27 02:11
I am using the zipfile module on a webserver which provides a service which processes files in zips uploaded by users, while hardening against zip bombs, I tried binary editing a zip to put in false file size information. The result is interesting, when with a ZIP_STORED file, or with carefully crafted ZIP_DEFLATED file (and perhaps ZIP_BZIP2 and ZIP_LZMA for craftier hackers than I), when the stated file size exceeds the size of the archive itself, ZipExtFile.read goes into an infinite loop, consuming 100% CPU.

The following methods on such an archive all result in an infinite loop:
ZipExtFile.read
ZipExtFile.read(n)
ZipExtFile.readlines
ZipFile.extract
ZipFile.extractall


ZipExtFile.read1 silently returns corrupt data but does not hang.

Obviously the module doesn't need to bend over backwards to deal gracefully with deliberately and maliciously crafted input, since all the user hopes for is to bring the program crashing down, but the 100% CPU infinite loop is probably one of the less satisfactory possible failure modes. It should either raise an exception or do something like read1 and silently return corrupt data.

This is low priority except for security since unless a zip is maliciously crafted some kind of exception will almost certainly be raised due to a decompression or invalid zip exception.
msg207307 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-01-04 20:37
Here is a patch with tests for all supported compression types.
msg207573 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-01-07 17:57
Looks as 2.7 is not affected.

If there are no objections I will commit this patch tomorrow.
msg207735 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-01-09 12:54
New changeset 0cf1defd5ac4 by Serhiy Storchaka in branch '3.3':
Issue #20078: Reading malformed zipfiles no longer hangs with 100% CPU
http://hg.python.org/cpython/rev/0cf1defd5ac4

New changeset 79ea4ce431b1 by Serhiy Storchaka in branch 'default':
Issue #20078: Reading malformed zipfiles no longer hangs with 100% CPU
http://hg.python.org/cpython/rev/79ea4ce431b1
msg207767 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-01-09 18:20
Thank you Nandiya for your report.
History
Date User Action Args
2022-04-11 14:57:55adminsetgithub: 64277
2014-01-09 18:20:51serhiy.storchakasetstatus: open -> closed
resolution: fixed
messages: + msg207767

stage: patch review -> resolved
2014-01-09 12:54:25python-devsetnosy: + python-dev
messages: + msg207735
2014-01-07 17:57:15serhiy.storchakasetmessages: + msg207573
versions: - Python 2.7
2014-01-04 20:37:52serhiy.storchakasetfiles: + zipfile_eof.patch
keywords: + patch
messages: + msg207307

stage: needs patch -> patch review
2013-12-27 18:18:25cvrebertsetnosy: + cvrebert
2013-12-27 09:42:36ronaldoussorensetnosy: + ronaldoussoren
2013-12-27 09:08:21serhiy.storchakasetassignee: serhiy.storchaka
stage: needs patch

nosy: + serhiy.storchaka
versions: + Python 3.4
2013-12-27 02:11:20nandiyacreate