2 ms·
> Options specified by cgo using #cgo CFLAGS and the like are now checked against a whitelist of permitted options. This closes a security hole in which a downl
by lima 9y ago
> Options specified by cgo using #cgo CFLAGS and the like are now checked against a whitelist of permitted options. This closes a security hole in which a downloaded package uses compiler options like -fplugin to run arbitrary code on the machine where it is being built.
How strong is the guarantee of "no code execution during build"?
I'm currently working on a Go build system and my understanding is that the Go compiler was designed for compiling untrusted code. You'd have to exploit the compiler on order to get RCE, right?
(I'm sandboxing it either way, but it's good to know for risk assessment)
- kjksf 9y agoHere's how it works. `go build` on a pure Go code only executes the compiler and linker of the go toolchain. If you add cgo to the mix, `go build` might invoke system C++ compiler (gcc, clang, mingw) to compile the C part of the code and system C++ linker. The issue was that gcc allows arbitrary plugins and if the right cgo flags were provided, gcc would load and execute such plugin, leading to executing whatever code was in the plugin. That hole was plugged in 1.10. This is the whole story. There are no other vectors of executing code that is not part of Go toolchain. Then again, what is your threat model? If you worry that blindly compiling my evil package will execute my evil code during build, you should also worry that linking my evil package will execute my evil code when you run your compiled executable.
- lima 9y agoThreat model is building (but not executing) untrusted code.