fix(security): 2 improvements across 2 files

[tomaioo]

Summary

fix(security): 2 improvements across 2 files

Problem

Severity: High | File: gcp/indexer/shared/shared.go:L57

The tar extraction logic joins tmpDir with hdr.Name and then cleans the result, but does not verify that the final path is still داخل tmpDir. A crafted tar entry such as ../../etc/passwd or an absolute path can escape the destination directory and overwrite arbitrary files on the host.

Solution

Before writing, validate each target path: reject absolute paths, reject .. traversal, and ensure strings.HasPrefix(resolvedPath, tmpDir+string(os.PathSeparator)). Also handle tar header types explicitly (regular files only) and reject symlinks/hardlinks.

Changes

• gcp/indexer/shared/shared.go (modified)
• go/cmd/exporter/writer.go (modified)

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[another-rex]

But... aren't we the ones writing the tars to the bucket in the first place?

[another-rex]

I probably don't mind merging this just as a defense in depth measure though

[tomaioo]

Good question—today we do produce those tarballs, but this extractor is still parsing untrusted input at runtime (bucket contents can be replaced, stale artifacts can persist, or write credentials can be abused).
Path traversal in archive extraction is a well-known high-impact class, so we should enforce safe extraction regardless of expected producer.
This is a defense-in-depth hardening: low code cost, and it prevents a single compromised artifact from writing outside tmpDir.

[tomaioo]

Good question—today we do produce those tarballs, but this extractor is still parsing untrusted input at runtime (bucket contents can be replaced, stale artifacts can persist, or write credentials can be abused).
Path traversal in archive extraction is a well-known high-impact class, so we should enforce safe extraction regardless of expected producer.
This is a defense-in-depth hardening: low code cost, and it prevents a single compromised artifact from writing outside tmpDir.

[tomaioo]

Good question—today we do produce those tarballs, but this extractor is still parsing untrusted input at runtime (bucket contents can be replaced, stale artifacts can persist, or write credentials can be abused).
Path traversal in archive extraction is a well-known high-impact class, so we should enforce safe extraction regardless of expected producer.
This is a defense-in-depth hardening: low code cost, and it prevents a single compromised artifact from writing outside tmpDir.

[tomaioo]

Good question—today we do produce those tarballs, but this extractor is still parsing untrusted input at runtime (bucket contents can be replaced, stale artifacts can persist, or write credentials can be abused).
Path traversal in archive extraction is a well-known high-impact class, so we should enforce safe extraction regardless of expected producer.
This is a defense-in-depth hardening: low code cost, and it prevents a single compromised artifact from writing outside tmpDir.