detect old (v7) tar headers when routing archives - #40
Open
abdul-khaliq-khalid wants to merge 1 commit into
Open
detect old (v7) tar headers when routing archives#40abdul-khaliq-khalid wants to merge 1 commit into
abdul-khaliq-khalid wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tar detection keys on the
ustarmagic at offset 257, but old (v7) archives carry no magic there at all, yettarfile.open(mode="r:*")reads them fine. A v7 tar therefore never reaches_extract_and_scan_archiveand none of its members get scanned, so the same malicious pickle that scoresunsafe: 3inside a ustar tar scoresunsafe: 0inside a v7 one. Repacking an archive as v7 is enough to slip a pickle past the scan.has_tar_headerkeeps the ustar fast path and falls back to verifying the 512-byte header checksum at offset 148, which is how magic-less v7 headers are normally identified; the two 262-byte peeks became 512 so the checksum is actually available. I put it inutilsand routed the five inline copies of the check through it so the formats stay in agreement, and I confirmed gnu/pax/zip/gzip and benign inputs classify exactly as before, with no false positives across 20k random 512-byte blobs.