cmd/go: arbitrary code execution during “go get” [Go 1.8] #23674
Comments
gopherbot
pushed a commit
that referenced
this issue
Feb 7, 2018
…r flags in #cgo directives Both gcc and clang accept an option -fplugin=code.so to load a plugin from the ELF shared object file code.so. Obviously that plugin can then do anything it wants during the build. This is contrary to the goal of "go get" never running untrusted code during the build. (What happens if you choose to run the result of the build is your responsibility.) Disallow this behavior by only allowing a small set of known command-line flags in #cgo CFLAGS directives (and #cgo LDFLAGS, etc). The new restrictions can be adjusted by the environment variables CGO_CFLAGS_ALLOW, CGO_CFLAGS_DISALLOW, and so on. See the documentation. In addition to excluding cgo-defined flags, we also have to make sure that when we pass file names on the command line, they don't look like flags. So we now refuse to build packages containing suspicious file names like -x.go. A wrinkle in all this is that GNU binutils uniformly accept @foo on the command line to mean "if the file foo exists, then substitute its contents for @foo in the command line". So we must also reject @x.go, flags and flag arguments beginning with @, and so on. Fixes #23674, CVE-2018-6574. Change-Id: I59e7c1355155c335a5c5ae0d2cf8fa7aa313940a Reviewed-on: https://team-review.git.corp.google.com/212688 Reviewed-by: Ian Lance Taylor <iant@google.com>
rsc
changed the title
|
The 1.8.7 release was made. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is a Go 1.8 tracking bug for the problem described in #23672.
See that issue for details and comments.
The text was updated successfully, but these errors were encountered: