Dear Python Community, 

We’ve found a vulnerability in cpython Lib and already received a cve number (CVE-2019-9674)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9674

We also have a patch for this vulnerability, please tell us what to do next.
Since we don’t want to uncover the vulnerability before it get fixed.

JUN-WEI SONG

Dear community,

I am one of the discoverer of this vulnerability, please tell us what to do next :D 

Kunyu Chen

You can find the process to report security vulnerabilities at https://www.python.org/news/security/ . Please email the details to security@python.org and who will analyze the report before public disclosure.

Thank you Karthikeyan Singaravelan.
We're working on it :D

Kunyu Chen

Issue #36462 contains more information. The reporter claims that the zipfile module is inherent insecure because it does not provide any heuristics to make zipbomb attacks harder.

I'm -1 to implement such a heuristic. The zipfile module is a low level module and should not limit extraction by defaykt. Instead we should improve documentation and maybe implement some method that simplifies detection of zipbomb attacks. I'm thinking about a method that returns total count of files, total compressed size and total uncompressed size.

All these are simple one-liners:

    len(zf.infolist())
    sum(zi.compress_size for zi in zf.infolist())
    sum(zi.file_size for zi in zf.infolist())

Thank you python community, these two issues are indeed the same problem.

I also think that it is good to make a related document to reduce such problems.

Thank you python community, these two issues are indeed the same problem.

I also think that it is good to make a related document to reduce such problems.

Thank you for the responses.

I agree with Christian Heimes.

It's indeed better to improve the documentation rather than directly implement the heuristic.

Hello Python community,

With Christian Heimes’ suggestion, we manipulate appropriate warning to inform users that they may encounter zip bomb issues when using the zipfile module.

The warning we would like to add in the zipfile documentation is shown below : 

https://github.com/python/cpython/blob/3.7/Doc/library/zipfile.rst

   .. warning::

    Never extract files from untrusted sources without prior 
    inspection. It is possible that the file may contain zip bomb 
    issues such as 42.zip. The zip bomb will usually be a small file 
    before decompression, but once it is decompressed, it will 
    exhaust system resources.

You can protect your system by limiting system resources, limiting compression ratio (zip bombs are usually quite high), and checking for nested zip files. 

We are also pleasure to provide a patch to enhance the zipfile module to provide basic information.

In zipfile.py

https://github.com/python/cpython/blob/master/Lib/zipfile.py

Inside the ZipFile class : 


def filecount(self):                                                                                         
    """Return total count of files in the archive."""                                                        
    return len(self.filelist)                                                                                
                                                                                                                 
def total_compressed_size(self):                                                                             
    """Return total compressed size in the archive."""                                                       
    return sum([data.compress_size for data in self.filelist])                                               
                                                                                                                 
def total_uncompressed_size(self):                                                                           
    """Return total uncompressed size in the archive."""                                                     
    return sum([data.file_size for data in self.filelist])

I am against such trivial methods in ZipFile. Its interface is already complicate. The advantage of Python is that you do not need tons of methods for every possible query -- you can just combine few Python features into a one-line expression.

As for the documentation change, it could be useful to add more general note about possible pitfalls. What happen when interrupt extracting or adding to the archive, what happen when extract into existing tree or overwrite an existing file, what happen when the file system does not support some file names, what happen when extract to case-insensitive file system, what happen when extract encrypted file with wrong password, etc. We do not have to tell the user what he should not do, just to warn about the possible consequences.

Hello Python community,

I’m curious why the patch or pitfall prevention in ZipFile
 are not suggested. I have no idea if everyone read documentation in detail. It seems straightforward to add the methods in ZipFile with well documented rather than just warn in documentation. Any comment would be appreciated.

Victor Kung

The suggested approach is merely a heuristic that reduces the impact of a zipbomb. An attacker can circumvent the heuristic. In best case scenario, the approach just increases the cost factor for a successful DoS. For example an attacker may have to upload 10 larger zip files instead of one smaller zip file to fill up the disk space of a server.

The correct approach is to always verify all data from untrusted sources. It's the 101 of application security.

I see. 

@Christian Heimes Thank you for the response.

Thank you very much for your reply. 


Based on discussions above, consensuses are improving the zipfile documentation. 


And we (JUN-WEI SONG &  KunYu Chen) would like to work on this. 


With opinions of Serhiy Storchaka, Christian Heimes and the ideas we have, possible pitfalls are listed below.


    1. From file itself: 

        Decompression may fail due to an incorrect password, an 
        incorrect CRC checksum, an incorrect PKZIP format, an 
        unsupported compression method, or an unsupported decryption.
 
    2. File system: 

        Each file system has different limitations such as allowable 
        characters in directory entries, the max length of file name, 
        the max length of path name, the max size of single file, the 
        max number of files, the max number of files in a single 
        directory, etc. Decompression will fail as long as these 
        limitations are exceeded.

     3. Operating system: 

        The lack of memory or disk space would lead to decompression 
        failed (see also Zip Bomb). 

     4. Interrupt: 

        Users should be careful in interrupting the process of 
        decompression, such as control-C or killing the process during 
        decompression, which may result in incomplete decompression of 
        the archive.

    5. Different default behaviors: 

        Users should figure out different default extraction behaviors, 
        such as when extracting into the existing tree, it will 
        overwriting an existing file without asking, or  when in a 
        case-insensitive file system, it keeps only one file when 
        extracting an archive which contains many files that have the 
        same name but different case. 


Please let us know if anything’s missing.

Dear friends,

We moved a little bit forward to improve the writing. :)

New changeset 3ba51d587f6897a45301ce9126300c14fcd4eba2 by Jason R. Coombs (JunWei Song) in branch 'master':
bpo-36260: Add pitfalls to zipfile module documentation (#13378)
https://github.com/python/cpython/commit/3ba51d587f6897a45301ce9126300c14fcd4eba2

New changeset c5a672315dffbc95acc1ca28584ec84ddb56626f by Jason R. Coombs (Miss Islington (bot)) in branch '3.8':
bpo-36260: Add pitfalls to zipfile module documentation (GH-13378) (GH-15976)
https://github.com/python/cpython/commit/c5a672315dffbc95acc1ca28584ec84ddb56626f

I marked bpo-39341 as a duplicate of this issue: "[security] zipfile: ZIP Bomb vulnerability, don't check announced uncompressed size".