Description
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.
- CVE-2018-25046
- CVE-2020-36560
- CVE-2020-36561
- CVE-2021-21272
- CVE-2020-36566
- Probably a bunch more.
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
Type
Projects
Status