Skip to content

fix: prevent path traversal in DownloadActionOutputs and validate symlink targets#650

Open
mohammadmseet-hue wants to merge 1 commit into
bazelbuild:masterfrom
mohammadmseet-hue:fix-path-traversal-variants
Open

fix: prevent path traversal in DownloadActionOutputs and validate symlink targets#650
mohammadmseet-hue wants to merge 1 commit into
bazelbuild:masterfrom
mohammadmseet-hue:fix-path-traversal-variants

Conversation

@mohammadmseet-hue

Copy link
Copy Markdown
Contributor

Summary

Two additional path traversal vectors were found in the download code path, both variants of the issue previously fixed in getAbsPath:

1. DownloadActionOutputs: os.RemoveAll with unvalidated dir.Path

DownloadActionOutputs passes dir.Path from the ActionResult proto directly to os.RemoveAll via filepath.Join, bypassing getAbsPath validation. A malicious remote execution server could set OutputDirectories[].Path to ../../important_data to delete arbitrary directories on the client filesystem.

The deletion happens at line 525 before DownloadOutputs (which validates paths via getAbsPath) is called at line 529.

2. DownloadOutputs: Symlink target not validated for containment

When creating symlinks from remote server output, the symlink placement path (out.Path) is validated via getAbsPath, but the symlink target (out.SymlinkTarget) is used directly from the proto without any validation. A malicious server can set SymlinkTarget to /etc/shadow or ../../../../etc/passwd, creating symlinks inside the output directory that point to arbitrary locations on the filesystem.

Fixes

  • Added getAbsPath validation in DownloadActionOutputs before os.RemoveAll
  • Added symlink target containment validation in DownloadOutputs using the same separator-aware prefix check as getAbsPath

…ownloadOutputs

Two path traversal variants were found in the download path:

1. DownloadActionOutputs passes dir.Path from the ActionResult proto
   directly to os.RemoveAll via filepath.Join, without validating it
   through getAbsPath. A malicious remote server could set dir.Path to
   "../../important_data" to delete arbitrary directories on the client.

2. DownloadOutputs creates symlinks without validating that the symlink
   target stays within the output directory. A malicious remote server
   could set SymlinkTarget to "/etc/shadow" or "../../../../etc/passwd"
   to create symlinks pointing outside the output directory, enabling
   arbitrary file read/write through symlink following.

Both fixes use the same getAbsPath validation introduced in the previous
path traversal fix, ensuring all server-controlled paths are validated
before use.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant