CHEF-38211: Reject path traversal via @LongLink entries in Tar extraction - #82
Merged
Merged
Conversation
The GNU '././@LongLink' extension read a destination path from entry content and assigned it to dest before the ignore_re filter ran and without File.expand_path, letting a subsequent innocent-looking entry be written to an attacker-controlled path outside the destination directory (bypassing the existing '..' filter from CVE-2017-1000026). Now the @LongLink-derived path is expanded, and a single containment check (applied to both @LongLink and regular entries) rejects any entry whose resolved destination falls outside the extraction root. Adds regression specs reproducing the BugCrowd PoC and confirming legitimate long-name entries still extract correctly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Thomas Powell <104777878+tpowell-progress@users.noreply.github.com>
Contributor
Author
rishichawda
approved these changes
Sep 18, 2026
sean-sype-simmons
approved these changes
Sep 18, 2026
tpowell-progress
added a commit
to chef/chef
that referenced
this pull request
Sep 21, 2026
Bumps mixlib-archive from 1.3.3 to 1.3.6 via bundle update --conservative, picking up chef/mixlib-archive#82 (CHEF-38211): a path-traversal fix in the pure-Ruby Tar backend where a malicious @LongLink long-name entry could set an unfiltered/unexpanded destination path, letting a later entry be written outside the extraction root. Also documents the bundle update --conservative workflow in .github/copilot-instructions.md for future gem bumps. Signed-off-by: Thomas Powell <104777878+tpowell-progress@users.noreply.github.com>
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
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.
Summary
Fixes a path-traversal vulnerability in the pure-Ruby Tar backend (
lib/mixlib/archive/tar.rb) reported via BugCrowd. The GNU././@LongLinklong-name extension assigned an attacker-controlled destination path todestbefore the existingignore_refilter ran and withoutFile.expand_path, allowing a subsequent innocent-looking entry to be written outside the extraction destination — bypassing the..filter added for CVE-2017-1000026 (no symlink required).Jira
CHEF-38211
Changes
lib/mixlib/archive/tar.rb: expand the@LongLink-derived path withFile.expand_path, and add a single containment check (applied to both@LongLinkand regular entries) that rejects any entry whose resolved destination falls outside the extraction root.spec/mixlib/tar_spec.rb: added regression specs reproducing the reported PoC (rejects the traversal payload) and confirming legitimate long-name entries still extract correctly.Tests & Coverage
Added 2 new specs covering the vulnerable branch; verified they fail against the pre-fix code and pass with the fix. Full suite (30 examples, 0 failures) and
rake style(cookstyle, 0 offenses) pass.Risk & Mitigations
Change is scoped to the extraction path-resolution logic only; behavior for legitimate archives (including long file names via
@LongLink) is unchanged, confirmed by regression test. Low risk, easily revertible via single commit revert.AI Assistance
This work was completed with AI assistance following Progress AI policies.