cmd/go: arbitrary code execution during “go get” or “go get -d” [Go 1.8]

[broady]

Using custom domains, it is possible to arrange things so that example.com/pkg1 points to a Subversion repository but example.com/pkg1/pkg2 points to a Git repository. If the Subversion repository includes a Git checkout in its pkg2 directory and some other work is done to ensure the proper ordering of operations, “go get” can be tricked into reusing this Git checkout for the fetch of code from pkg2. If the Subversion repository’s Git checkout has a malicious code in .git/hooks/, it will execute on the system running “go get.”

The fix is to detect version control checkouts nested inside other version control checkouts and refuse to execute version control operations in those checkouts. It would be nice if Git had a --no-hooks option, and then we could use that as an additional backup step, but it does not.

Fixed in Go 1.8.4 by CL 68190 (a4544a0).
Fixed in Go 1.9.1 by CL 68022 (a39bcec).

Thanks to Simon Rawet for reporting this problem.

Update: This has been assigned CVE-2017-15041.

[dmitshur]

Doesn't this need to be applied to golang.org/x/tools/go/vcs package as well (due to #11490 not being resolved)? Is there an existing issue tracking that?

Edit: Done in CL 68352.

[gopherbot]

Change https://golang.org/cl/68352 mentions this issue: go/vcs: reject update of VCS inside VCS

[artursapek]

This change seems to break go get on a nested bzr package called labix.org/v2/mgo.

Given command go get labix.org/v2/mgo/bson, we get this output:

package labix.org/v2/mgo/bson: directory "/home/emile/go/src/labix.org/v2/mgo" uses bzr, but parent "/home/emile/go/src/labix.org/v2" uses bzr

Same goes for this mirror: go get gopkg.in/mgo.v2/bson

Was the intent here to disable all nested VCS except for git?

[KilledKenny]

@artursapek That bad we didn't know that nested bzr was allowed while developing this fix.
The goal was to prevent malicious uses of mixing VCS.
The reason why git was allowed inside git was because that was know safe behavior.

[artursapek]

@KilledKenny ok, might be worth adding an exception for bzr as well if it's deemed safe. I know this mgo package is pretty popular and these changes broke installation for it. That said I do wish they would just use git, I mean come on : )

[rsc]

Thanks @artursapek; filed #22157.

[rsc]

Update: This has been assigned CVE-2017-15041. (Also added to top comment.)