Skip to content

archive/tar, archive/zip: add ErrInsecurePath #55356

Open
@neild

Description

@neild

This is an alternative fix for #25849, as proposed by @dsnet in #25849 (comment).

The archive/tar and archive/zip readers return unsanitized paths from archives. Careless use of these paths leads to path traversal attacks.

Proposal:

An insecure filename is an absolute path, or a path containing a relative path component (../).
When tar.Reader.Next reads a file with an insecure filename, it returns tar.ErrInsecurePath.
When zip.NewReader opens an archive containing an insecure filename, it returns zip.ErrInsecurePath.
In both cases, the function also returns a usable object (a *tar.Header or *zip.Reader).

In the case where the caller wants to handle archives with insecure filenames, they may ignore the ErrInsecurePath error and perform whatever sanitization they find appropriate. If the caller takes no action, they get an error when processing an unsafe archive.

The advantage over automatically sanitizing filenames is that we don't silently change the semantics of archives. A tar archive may legitimately contain absolute path names; silently converting these to relative names seems more surprising than reporting an error. In addition, there isn't always an obvious sanitized name--we probably want to reject the name COM1 on Windows, but what would we rewrite it into?

Metadata

Metadata

Assignees

Labels

NeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.ProposalProposal-AcceptedSecurity

Type

No type

Projects

Status

Accepted

Relationships

None yet

Development

No branches or pull requests

Issue actions