Skip to content

Python "zipfile" can't detect "quoted-overlap" zipbomb that can be used as a DoS attack #109858

Closed

Description

@dyingc

Bug report

Bug description:

Just found this vulnerability in the latest Python 3.11.5 (and previous 3.10.10).

If we craft a zipbomb using the "quoted-overlap" way (as mentioned https://www.bamsoftware.com/hacks/zipbomb/), this can't be detected by Python's zip file and the zip will be extracted and thus potentially cause a DoS attack by consuming all the storage.

This issue is related to CVE-2019-9674 but not the same. CVE-2019-9674 is talking about the "normal" overlap-zipbomb which is a "full" overlap. This can already be detected by Python's new version of zipfile. However, when we craft a "quoted-overlap" zip, as indicated by https://www.bamsoftware.com/hacks/zipbomb/, python can't detect and happily starts to extract.

For example, the following is the python to extract a zip file, 116 KB before extraction, goes to as large as 17GB after extraction. The size after extraction can be easily increased to multi TBs or even PBs by adjusting the zip-creation.

import zipfile
import sys
import os

def extract_zip(zip_path):
    """
    Extracts the contents of a ZIP file to the current directory.

    :param zip_path: Path to the ZIP file
    """
    if not os.path.exists(zip_path):
        print(f"Error: {zip_path} does not exist.")
        return

    with zipfile.ZipFile(zip_path, 'r') as zip_ref:
        zip_ref.extractall()
        print(f"Extracted contents of {zip_path} to the current directory.")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python extract_zip.py <path_to_zip_file>")
        sys.exit(1)

    zip_file_path = sys.argv[1]
    extract_zip(zip_file_path)

CPython versions tested on:

3.11

Operating systems tested on:

Linux

Linked PRs

Activity

  1. added a commit that references this issue on Sep 28, 2023
  2. serhiy-storchaka commented on Sep 28, 2023

    @serhiy-storchaka
    Member

    As a workaround, the following check can be used before extracting a ZIP file.

    # zipf is an open ZipFile
    end_offset = zipf.start_dir
    for zinfo in sorted(zipf.filelist,
                        key=lambda zinfo: zinfo.header_offset,
                        reverse=True):
        if zinfo.header_offset + zinfo.compress_size > end_offset:
            raise zipfile.BadZipFile('Overlapped entries')
        end_offset = zinfo.header_offset

    Edited to remove a suggestion of using reversed rather than sorted. Assume that nefarious zips will intentionally not follow "normal" patterns of having the central directory in the same order, the sorting defends against that.

  3. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Nov 24, 2023
  4. gpshead commented on Jan 2, 2024

    @gpshead
    Member

    But if the ZIP file was modified in-place after creation, the order can be changed, so it is up to you whether you want to support such corner case.

    Applications wanting to do that seem rare & overcomplicated enough that I'd just call that an application design issue corner case that we don't need to spend extra effort to worry about ourselves.

  5. moved this from Todo to In Progress in Zipfile issues 📦on Jan 2, 2024
  6. added a commit that references this issue on Jan 10, 2024
  7. added 4 commits that reference this issue on Jan 10, 2024
  8. added a commit that references this issue on Jan 10, 2024
  9. added 11 commits that reference this issue on Jan 10, 2024
  10. serhiy-storchaka commented on Jan 11, 2024

    @serhiy-storchaka
    Member

    Backports already include the #113918 fix, so they can just be merged.

  11. added 3 commits that reference this issue on Jan 17, 2024
  12. added 2 commits that reference this issue on Jan 22, 2024
  13. pablogsal commented on Feb 5, 2024

    @pablogsal
    Member

    This is marked as a release blocker including the 3.11 tag but the issue is still open. It's there anything left here?

  14. serhiy-storchaka commented on Feb 5, 2024

    @serhiy-storchaka
    Member

    No. All necessary backports were merged. Thank you for the reminder.

  15. moved this from In Progress to Done in Zipfile issues 📦on Feb 5, 2024
  16. added 2 commits that reference this issue on Feb 11, 2024
  17. sparrowt commented on Apr 3, 2024

    @sparrowt
    Contributor

    Does anyone here have any contacts in GitHub who know about GHSA?

    Their entry for this (CVE-2024-0450) GHSA-jm46-725r-hh9v says that 3.12.2 and 3.11.8 are vulnerable, but AFAICS those 2 versions contain the fix (see gh-109858 mentioned in 3.12.2 release notes and 3.11.8 release notes).

    I've attempted to open an improvement PR here but I'm not sure if it will be accepted seeing as it says 'Unreviewed' and it seems python is not on the list of things they care about; because the "suggest improvements" button (via which I did it) forced me to select "Affected products" where [c]python was not an option 😢 the nearest thing was 'pip'.

    AFAICS this GHSA data feeds through into tools like Grype which currently say "Fixed?"=unknown and have no "Fixed in" so it would be good to know how to correct the record on which python versions are vulnerable/fixed.

  18. sethmlarson commented on Apr 3, 2024

    @sethmlarson
    Contributor

    Thanks for reporting this @sparrowt, I'll take a look and update the CVE records accordingly. In theory this will trickle down into GitHub Security Advisories as well since they source a lot of their information from that database.

  19. sparrowt commented on Apr 3, 2024

    @sparrowt
    Contributor

    Amazing thank you! I'm not sure how the affected versions / patched versions thing is going to work given GHSA seems to only support packages within certain 'ecosystems' but seemingly not the ecosystem runtime (e.g. python) itself:
    image

  20. sethmlarson commented on Apr 3, 2024

    @sethmlarson
    Contributor

    I've fixed the metadata for the CVE. I believe the "syncing" process will happen outside of the manual update process but could be wrong? The GHSA team is aware of the whole ecosystem issue for updating GHSA records.

  21. added a commit that references this issue on Apr 25, 2024
  22. sparrowt commented on May 15, 2024

    @sparrowt
    Contributor

    Thanks! Sadly it's still wrong on GHSA-jm46-725r-hh9v

  23. added a commit that references this issue on May 16, 2024
  24. added 2 commits that reference this issue on Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

3.10 (EOL)end of life3.11only security fixes3.12only security fixes3.13only security fixes3.8 (EOL)end of life3.9 (EOL)end of liferelease-blockerstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or errortype-securityA security issue

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions