archive/zip: sanitize the FileHeader.Name to remove path traversal ("../../") from zip files?

[bradfitz]

Go isn't directly affected by path traversal attacks in archives but programs written in Go might be.

In particular, if a Go program reads a malicious zip file, the archive/zip package will return the malicious filename in the FileHeader.FileName.

Perhaps we should sanitize it?

If we really need the raw/unsanitized version, we could copy it to a new field FileHeader.InsecureFileName or RawFilename or something.

/cc @dsnet @ianlancetaylor @FiloSottile @andybons @rsc

[bradfitz]

/cc @mholt too, author of github.com/mholt/archiver (pointed out by @dsnet), which properly sanitizes paths on its own. But maybe that shouldn't be its job.

[dsnet]

I'm of the opinion that it's the users responsibility to sanitize the path, as I have seen some crazy (and very rare) use-cases in the past actually depending on this behavior. We should document this though.

As a data point, a popular package that wraps the standard archive package is github.com/mholt/archiver, which handles it properly.

[dsnet]

Hmmm, as a counter-point, it seems that the logic in archiver was added precisely because of zip-slip:
mholt/archiver#65

[bradfitz]

I think we should be safe by default but provide access to the unsanitized value for the "crazy" use cases you mention.

[dsnet]

One proposal is to return a distinguishable error when an invalid path is encountered, but still parse out (or write) the full header. Odd use cases can check for that specific semantic error and ignore it, but most users will be protected.

[FiloSottile]

+1 on sanitizing FileName and adding InsecureFileName. Looks like this applies to archive/tar as well. We'll also have to make absolute paths relative.

However, note that it's not enough to prevent all path traversal attacks. For example, allowing symlinks with arbitrary targets (like ../../) in a tar archive can still results in an escape even if filenames are clean. Sanitizing symlink targets might break more things than filenames.

See https://blog.filippo.io/so-i-lost-the-password-of-my-nas/ section 3 for example.

[FiloSottile]

And it was already reported against github.com/mholt/archiver: mholt/archiver#65 (comment)

[bradfitz]

One proposal is to return a distinguishable error when an invalid path is encountered, but still parse out (or write) the full header.

I like that.

It'd mean only adding a new error variable (or type) to the package, and some docs on two functions.

However, note that it's not enough to prevent all path traversal attacks. For example, allowing symlinks with arbitrary targets (like ../../) in a tar archive can still results in an escape even if filenames are clean. Sanitizing symlink targets might break more things than filenames.

This is more work, but not terrible. We could track them all and still detect when another name would reference a path element with a link. Without that, though, fortunately the number of affected callers is probably fewer because you need to go out of your way to support symlinks. If the caller program is, say, a webapp letting users upload a zip of JPEGs, they probably didn't add in the symlink creation support.

Let's start with some more documentation for Go 1.11.

[gopherbot]

Change https://golang.org/cl/118335 mentions this issue: archive/zip: warn about FileHeader.Name being unvalidated on read

[slrz]

+1 on sanitizing FileName and adding InsecureFileName. Looks like this applies to archive/tar as well. We'll also have to make absolute paths relative.

I'm not comfortable with doing this for archive/tar. Absolute pathnames are common usage there and writing to /etc/passwd is often intended. Returning an error where there was none before is going to break existing programs.

[mholt]

I probably should not have open-sourced my archiver package, since I only use it to compress, and only in non-adversarial environments. Sorry if it caused any trouble. (I don't have much time to maintain it lately, so if anyone wants to do so, I'll make you a collaborator.)

Thanks for thinking of this aspect of security, though, from the standard library perspective. Admittedly it's hard to do path sanitization right, since there are some use cases, as others have mentioned, where "unsafe" sanitization may be desired. And I keep getting path cleanup wrong myself (did at least 3 times in Caddy too).

Whatever you decide, I vote for sane defaults with the option to shoot yourself in the foot if need be, with strongly-worded warnings in the godocs. :)