Skip to content

security: tar extraction can escape through chained symlink sequence (Z-001) #920

Description

@PierrunoYT

Description

The tar extraction logic in internal/update/extract.go is vulnerable to a chained symbolic link escape. While the current implementation performs lexical checks to ensure paths remain within the destination directory (using ilepath.Join and similar string-based collapsing), it fails to account for the actual resolution on the filesystem.

Since the extraction process writes files using paths that follow real filesystem symlinks without employing O_NOFOLLOW, an attacker can craft a malicious archive containing a chain of symlinks that resolve progressively outside the target directory. For example:

  • � $\rightarrow$ . (resolves to destination, passes check)
  • � $\rightarrow$ �/.. (lexically collapses to destination, but on disk resolves to parent of destination)
  • c $\rightarrow$ �/.. (resolves further out)

Impact

This vulnerability allows for arbitrary file writes as the user executing zero upgrade. Because this command is frequently run with elevated privileges for system-wide installations, this can be leveraged to achieve root or administrator level persistence on the host system.

Recommended Fixes

  1. Strict Rejection: Reject any archive entry of type ar.TypeSymlink in release archives entirely, matching the security posture of the zip extraction path.
  2. Rooted Descriptors: Implement extraction using an openat-relative descriptor chain rooted at the destination directory, ensuring O_NOFOLLOW is applied to every component of the path to prevent traversal via symlinks.
  3. Identity Verification: Ensure the promotion stage continues to use the existing descriptor-bound rename and O_NOFOLLOW checks already present in internal/update/stage_other.go.

Activity

  1. added
    issue-approvedReviewed and approved by the core team; community PRs may implement this issue.
    on Aug 25, 2026
  2. gnanam1990 commented on Aug 25, 2026

    @gnanam1990
    Collaborator

    Approved after rechecking the extractor. Current main accepts tar.TypeSymlink entries and later opens destination paths through normal pathname resolution, so lexical containment does not bind the filesystem object being written. PR #943 is already active; review should require a regression that fails on the chained-symlink sequence.

  3. added a commit that references this issue on Aug 29, 2026
    201e6fc
  4. added a commit that references this issue on Sep 12, 2026
    deba3ad
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    issue-approvedReviewed and approved by the core team; community PRs may implement this issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions