Skip to content

Remove backtracking from parsing tarfile members and headers #121285

Closed

Description

@sethmlarson

Activity

  1. added a commit that references this issue on Aug 31, 2024
  2. added 2 commits that reference this issue on Aug 31, 2024
  3. gpshead commented on Aug 31, 2024

    @gpshead
    Member

    main version merged. I'll let you work out any non-automatic backports.

  4. added a commit that references this issue on Aug 31, 2024
  5. added
    stdlibStandard Library Python modules in the Lib/ directory
    3.11only security fixes
    3.13only security fixes
    on Sep 1, 2024
  6. 4 remaining items

  7. added 3 commits that reference this issue on Sep 3, 2024
  8. added 2 commits that reference this issue on Sep 3, 2024
  9. frenzymadness commented on Sep 4, 2024

    @frenzymadness
    Contributor

    The CVE description contains:

    Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.

    but the test added to verify the fix does not cause/test the ReDoS. I mean, when you run the test with unpatched Python, it raises tarfile.ReadError as well just with a different message, for example:

    tarfile.ReadError: file could not be opened successfully:
    - method gz: ReadError('not a gzip file')
    - method bz2: ReadError('not a bzip2 file')
    - method xz: ReadError('not an lzma file')
    - method tar: ReadError('bad checksum')
    

    Could you please help me understand how one of the regexes (fox example: br"(\d+) ([^=]+)=") can cause a regex backtracking? There is no combination of greedy nested quatifiers, greedy quantifiers are limited by the character class and I don't see a need for the regex algorithm to go back and consider another path if the match is not found.

  10. sethmlarson commented on Sep 4, 2024

    @sethmlarson
    ContributorAuthor

    @frenzymadness Apologies for the confusion, not all of the regular expressions in the PR have issues with backtracking. The regex you mention was replaced to process the entire tar header block in one pass rather than multiple passes.

  11. added 2 commits that reference this issue on Sep 4, 2024
  12. added 2 commits that reference this issue on Sep 5, 2024
  13. mcepl commented on Sep 18, 2024

    @mcepl
    Contributor

    Patch for Python 3.8 applies more or less painlessly on the 3.6 branch as well.

  14. added a commit that references this issue on Oct 9, 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.13only security fixes3.8 (EOL)end of life3.9 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directorytype-securityA security issue

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions