This month Google engineers patched a serious remote code execution (RCE) vulnerability in the Go language (Golang).
The RCE vulnerability, CVE-2021-3115, primarily affects Windows users running the go get, due to the default behavior of Windows PATH lookups.
Recently, security researcher RyotaK discovered a command injection vulnerability in the Golang project.
The vulnerability, designated as CVE-2021-3115, stems from the way the compilation process works when a user executes the “go get” command to “fetch” a repository.
Generally, on Windows systems, an "OS shell command" executed by the user or a program causes the shell to first search for the binary/executable associated with that command in the current directory, followed by a list of directories specified in the PATH system variable.
For example, if you type netstat at a Windows command prompt, Windows would first look for a netstat.exe, netstat.bat, or other netstat.* executable in the current directory (see screenshot below) which would take precedence and be executed.
If netstat in the current folder, only then would the Windows shell look for the netstat system utility, the location of which exists in the Windows %PATH% variable.
Due to the security risks associated with this behavior, both the Unix shell and Windows PowerShell had previously abandoned this default behavior and began prioritizing %PATH% variable locations from the untrusted current directory when executing commands.
This means that running netstat in PowerShell will launch the system utility netstat and not the locally present netstat.bat, since PoweShell prioritizes searching for the binary with that name in the %PATH% directories.
However, for consistency, Golang binaries emulate Unix rules for Unix systems and Windows rules for Windows.
This means that running the following Go command will produce slightly different behaviors on Unix and Windows systems.
This “Golang line” is equivalent to executing the “OS shell command' go version.
On Windows, a local go binary would take precedence, while Unix systems would search the $PATH variable to see if a go exists in one of the trusted locations.
This model of prioritizing local, untrusted directories in PATH locations is also implemented by utility libraries and compilers included with Go, such as cgo, a utility designed to create Go packages that call C code.
When cgo compiles C code on Windows, the Golang executable eventually looks for the GCCcompiler in the (untrusted) local directory.
Although most of these calls are made in a safe manner, the GCC compiler is called by exec.Command , which, on Windows, allows Go to launch a malicious gcc.exe included by the hacker in the application sources, instead of the legitimate GCC compiler.
It may seem like this issue could have been detected and prevented by many intermediate compilers and libraries that are invoked (like cgo or gcc), but the team behind Golang took responsibility for the bug and issued a fix.
Google's Golang team has patched the vulnerability and users are advised to upgrade their instances. Users can upgrade to the recently released Go versions 1.14.14 (for 1.14.x and earlier) and 1.15.7 (for 1.15.x users) to mitigate this vulnerability.
Information source: bleepingcomputer.com
