Go: cmd/go: arbitrary code execution during “go get”

Created on 2 Feb 2018 · 12Comments · Source: golang/go

Go get downloads and builds source code. It is not meant to execute arbitrary code.

When cgo is enabled, the build step during “go get” invokes the host C compiler, gcc or clang, adding compiler flags specified in the Go source files. Both gcc and clang support a plugin mechanism in which a shared-library plugin is loaded into the compiler, as directed by compiler flags. This means that a Go package repository can contain an attack.so file along with a Go source file that says (for example) // #cgo CFLAGS: -fplugin=attack.so, causing the attack plugin to be loaded into the host C compiler during the build. Gcc and clang plugins are completely unrestricted in their access to the host system.

Thanks to Christopher Brown of Mattermost for reporting this problem.

This issue is CVE-2018-6574.

Fixed in Go 1.8.7 by commit 44821583bc16.
Fixed in Go 1.9.4 by commit 867fb18b6d5b.
Fixed in Go 1.10rc2 by commit 1dcb5836ad2c.

The fix changes “go build” (used during “go get” and “go install”) to limit the flags that can appear in Go source file #cgo directives to a list of allowed compiler flags; -fplugin= and other variants are not on the allowed list. The same restrictions are applied to compiler flags obtained from pkg-config. Flags obtained from the environment variables $CGO_CFLAGS and so on are not restricted, since those variables can only be set by the user running the build. To change the set of allowed compiler flags, new environment variables $CGO_CFLAGS_ALLOW and $CGO_CFLAGS_DISALLOW can set to regular expressions matching additional allowed and disallowed flags. Run “go doc cgo” for details.

Code that passes a flag and argument pair to the linker must now use one -Wl flag instead of two: use #cgo LDFLAGS: -Wl,-rpath,$ORIGIN, not #cgo LDFLAGS: -Wl,-rpath -Wl,$ORIGIN.

Also, //go:cgo... directives, including //go:cgo_ldflag, are now disallowed except in cgo-generated source code and some special cases in the standard library. Packages outside the standard library that attempt to use these directives will no longer build.

FrozenDueToAge Security

Source

rsc

👍65

Most helpful comment

Compiling sources always involves trust in the sources to be compiled. You could attack the compiler itself (both clang and gcc do not claim to handle hostile input) or just embed malicious code in the executable to be compiled.

While arguments to cgo should be sanitized, I really think we should not encourage the believe that go get on untrusted sources is a secure operation.

ooxi on 10 Feb 2018

👍21 👎1

All 12 comments

Consider these compiler flags:

-fno-rtti
-fpermissive

And also -framework as a linker option:

-Wl,-framework

See go-libutp and go-gtk.

anacrolix on 8 Feb 2018

In the case of go-gtk, these flags are provided from pkg-config. Fortunately, I could build go-gtk on Windows. I still not confirm Linux.

mattn on 8 Feb 2018

https://github.com/miekg/pkcs11/issues/63 - go1.9.4 breaks building github.com/miekg/pkcs11 on Linux as it does not allow -Wl,--no-as-needed - could that flag be added, please? Otherwise users would have to run install and test as CGO_LDFLAGS_ALLOW='-Wl,--no-as-needed' go install and it will break lots of CI builds.

dmitris on 8 Feb 2018

I've opened #23749 as a place to collect options that should be added to the whitelists.

ianlancetaylor on 8 Feb 2018

While arguments to cgo should be sanitized, I really think we should not encourage the believe that go get on untrusted sources is a secure operation.

ooxi on 10 Feb 2018

👍21 👎1

Please add these linker flags to the white list
-Wl,-Bstatic
-Wl,-Bdynamic
-Wl,--start-group
-Wl,--end-group