You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove backtracking from parsing tarfile members and headers #121285
Today the tarfile module parsing of header values allows for backtracking when parsing header values. Headers have a well-known format that doesn't require backtracking to parse reliably, the new method of parsing will only require a single pass over a byte stream.
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.
@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.
Activity
gh-121285: Remove backtracking when parsing tarfile headers (GH-121286)
pythongh-121285: Remove backtracking when parsing tarfile headers (py…
pythongh-121285: Remove backtracking when parsing tarfile headers (py…
gpshead commentedon Aug 31, 2024
mainversion merged. I'll let you work out any non-automatic backports.[3.12] gh-121285: Remove backtracking when parsing tarfile headers (G…
4 remaining items
[3.10] pythongh-121285: Remove backtracking when parsing tarfile head…
[3.9] pythongh-121285: Remove backtracking when parsing tarfile heade…
[3.8] pythongh-121285: Remove backtracking when parsing tarfile heade…
[3.11] gh-121285: Remove backtracking when parsing tarfile headers (G…
[3.10] gh-121285: Remove backtracking when parsing tarfile headers (G…
frenzymadness commentedon Sep 4, 2024
The CVE description contains:
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.ReadErroras well just with a different message, for example: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.sethmlarson commentedon Sep 4, 2024
@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.
[3.8] gh-121285: Remove backtracking when parsing tarfile headers (GH…
[3.9] gh-121285: Remove backtracking when parsing tarfile headers (GH…
00437: [3.8] pythongh-121285: Remove backtracking when parsing tarfil…
00437: [3.8] pythongh-121285: Remove backtracking when parsing tarfil…
mcepl commentedon Sep 18, 2024
Patch for Python 3.8 applies more or less painlessly on the 3.6 branch as well.
[CVE-2024-6232] Remove backtracking when parsing tarfile headers