Skip to content

path/filepath: Join is susceptible to SlipZip #40373

@rminnich

Description

@rminnich

Edit: moved from issue title to body for hyperlink: https://snyk.io/research/zip-slip-vulnerability


The u-root project has several programs that unarchive files -- cpio, tar, zip, etc.

A few weeks ago we were notified that we are vulnerable to something called ZipSlip. It's a simple enough problem: archives containing paths with .. can end up in unexpected places.

e.g., I am in /bin, and I unpack a cpio, I expect things to end up /bin, and they end up in /home/rminnich/bin/wildthing

This is an easy thing to fix: given a root, base, and a path, p: filepath.Join("/some/place", filepath.Join("/", p))
I can contain the files to base.

The bigger question: do people in general expect that for filepath.Join, things won't creep out of the first directory argument to other places? 3 different people wrote 3 different tools on u-root and missed this, I think because they assumed that everything stayed under path.

This seems like an accident waiting to happen, save that it already did.

Should filepath.Join be changed, or maybe we need a filepath.BaseJoin which guarantees things stay inside the base?

I can fix this for the 3 programs in question, but I'm wondering if it really belongs in the go runtime instead.

What version of Go are you using (go version)?

go version go1.14.3 darwin/amd64

Does this issue reproduce with the latest release?

Repros on every release since filepath.Join was written.

What operating system and processor architecture are you using (go env)?

Does not matter -- it's a filepath question

What did you do?

package main

import "fmt"
import "path/filepath"

func main() {
	fmt.Println(filepath.Join("/bin", "../../cat"))
	fmt.Println(filepath.Join("/bin", filepath.Join("/", "../../cat")))
}

What did you expect to see?

people don't expect to see files creep out of the target directory. Arguably it's a defect of the program, and a bad assumption on the part of the author(s), but still ...

What did you see instead?

We got a CVE ;-)

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions