Google Fixes RCE Vulnerability in Golang Language

Google engineers have eliminated the dangerous vulnerability (CVE-2021-3115) A remote code execution in the language of Go (Golang), affecting Windows user that executes instructions go get.

The vulnerability was discovered by a Japanese security researcher using the RyotaK alias and is related to the way the compilation process works when the user runs the "go get" command to get the repository.

Typically, on Windows systems, an OS shell command, run by a user or program, forces the shell to first look for the binary / executable file associated with that command in the current directory, and then the directory listing specified in the system PATH variable.

For example, if the user types netstat at the Windows command prompt, the OS will first look for the netstat.exe, netstat.bat, or other netstat executable. in the current directory, which will take priority and be executed. If there is no netstat in the current folder, then the Windows shell will look for the system utility netstat, the location of which is specified in the% PATH% Windows variable.

Because of the security risks associated with this behavior, the Unix shell and Windows PowerShell developers have previously deprecated this default behavior and made preference to the location of% PATH% variables over the untrusted current directory when executing commands.

Thus, running netstat in PowerShell will launch the system utility netstat rather than the locally present netstat.bat, since PoweShell gives priority to looking for a binary file by that name in the% PATH% directories.

For consistency, Golang binaries mimic the Unix and Windows rules on their respective systems. Because of this, executing the following Go command will result in slightly different behavior.

On Windows, a locally present go binary will take precedence, whereas Unix systems will first look for their $ PATH variable to see if the go binary exists in one of the trusted locations.

This model of prioritizing a local, untrusted directory over PATH locations is also implemented by helper libraries and compilers included with Go, such as cgo (a utility for generating Go packages). When cgo compiles C code on Windows, eventually the Golang executable looks for the GCC compiler in an untrusted local directory first.

While most of these calls are safe, the GCC compiler is called by the Go exec.Command function, which on Windows allows Go to run the malicious gcc.exe included in its application sources by the attacker, rather than the legitimate GCC compiler.

Previous Post Next Post