archive/tar, archive/zip: add ErrInsecurePath

[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.

• 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?

[dsnet]

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?

It isn't clear to me whether the proposal includes returning ErrInsecurePath for a file named "COM1". I don't really see that as a security vulnerability since Windows won't let me create a file by that name anyways.

[neild]

filepath.IsAbs considers COM1 and a number of other reserved names to be absolute:
https://go.googlesource.com/go/+/refs/tags/go1.19.1/src/path/filepath/path_windows.go#23

Using filepath does mean that whether an archive is insecure or not will depend on the platform we're executing on, but I think that's better than the alternatives. (On one hand, we shouldn't treat reserved names as safe on Windows; on the other hand, we shouldn't reject them elsewhere.)

[dsnet]

Using filepath does mean that whether an archive is insecure or not will depend on the platform we're executing on

I find that behavior to be fairly surprising. Suppose someone were writing a service that you can send ZIP and TAR files to and it would report whether they are "safe". I would expect the answer given by the service to be agnostic to the platform it is running on. The example might seem esoteric, but it's not that far fetched from how Gmail auto-scans attachments for viruses.

[dsnet]

In general, I would not expect archive/zip or archive/tar to depend on path/filepath for anything directly used by the Reader or Writer.

The only OS-specific behavior is isolated within functionality that deal with fs.FileInfo (e.g., zip.FieInfoHeader and tar.FileInfoHeader).

[bcmills]

@dsnet

I don't really see that as a security vulnerability since Windows won't let me create a file by that name anyways.

I expect that many users of the archive packages use os.WriteFile to write their contents. Unfortunately, neither os.Create nor os.WriteFile sets O_EXCL when creating the file — would it silently write the contents to COM1 instead of failing?

[neild]

So far as I can see, we can:

1. Call an archive containing the file com1 insecure on all systems. This doesn't seem right; Unix systems shouldn't need to worry about Windows special file names.
2. Call an archive containing the file com1 secure on Windows. This is definitely not right; our goal is to ensure that os.WriteFile with an archive filename is safe by default.
3. Accept inconsistency and apply OS-specific behavior.

Of these options, OS-specific behavior seems the least objectionable to me.

[bcmills]

There are also variations on (1) and (3) that we could consider: we could add a field or method to the Reader structs to allow callers to modify the validation hook.

1a. Call an archive containing the file com1 insecure by default on all systems, but make it easy to configure to accept those names on non-Windows platforms.
3a. Accept inconsistency and apply OS-specific behavior by default, but make it easy to configure to reject names that are insecure on any system.

(1a) provides better default security, but (3a) provides better backward-compatibility for existing users on Unix. 🤔

[bcmills]

When zip.NewReader opens an archive containing an insecure filename, it returns zip.ErrInsecurePath.

Hmm. It's not clear to me how would override that behavior if (for example) one is writing the data to an isolated in-memory database rather than the local filesystem. Would it make sense to return the error from the *File methods instead (Open, OpenRaw, and maybe DataOffset), so that the caller has an opportunity to set an override of some kind in the FIle struct ahead of the call?

[neild]

We would return ErrInsecurePath when encountering an insecure filename, but permit the user to ignore it. So:

zr, err := zip.NewReader(r, size)
if err == zip.ErrInsecurePath {
  err = nil // we will perform our own path sanitization
}
if err != nil {
  return err
}