Skip to content

CHEF-38211: Reject path traversal via @LongLink entries in Tar extraction - #82

Merged
tpowell-progress merged 1 commit into
mainfrom
CHEF-38211
Sep 18, 2026
Merged

tpowell-progress merged 1 commit into
mainfrom
CHEF-38211

Conversation

@tpowell-progress

@tpowell-progress tpowell-progress commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes a path-traversal vulnerability in the pure-Ruby Tar backend (lib/mixlib/archive/tar.rb) reported via BugCrowd. The GNU ././@LongLink long-name extension assigned an attacker-controlled destination path to dest before the existing ignore_re filter ran and without File.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 with File.expand_path, and add a single containment check (applied to both @LongLink and 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.

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>
@tpowell-progress tpowell-progress added the ai-assisted Work completed with AI assistance following Progress AI policies label Sep 18, 2026
@tpowell-progress

Copy link
Copy Markdown
Contributor Author

@tpowell-progress
tpowell-progress merged commit 8111173 into main Sep 18, 2026
41 checks passed
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai-assisted Work completed with AI assistance following Progress AI policies

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants