Top 5 Go Vulnerabilities That You Should Know
Table of Contents
When the vulnerabilities get tough, the tough get Going.
Google’s Go programming language has been rocketing up the ranks in popularity, fast becoming a favorite for developers and companies everywhere.
Released by the good folks at Google in 2012, Go has been declared as the 7th fastest language by GitHub, and cracked into the IEEE Top Ten list in 2018 when it came in at the number 5 spot.
Go is beloved for its ability to help developers work more productively on large scale projects that require high-level networking and multiprocessing. Its general readability and usability along the lines of Python have also helped in extending its reach beyond Google’s suite of in-house products out to the wider community. Netflix, Uber, and CloudFlare are just some of the organizations that use Go for building their products.
As more companies are using open source components written in Go in their code, it’s important that they stay secure when it comes to known vulnerabilities that impact those components. Since these components are often used in multiple projects, a single vulnerability in one component can be used to exploit a wide range of products if developers do not move quickly to remediate.
Go is a relatively new language on the scene, which means that it does not have the long history of vulnerabilities of say a Java or C. However, as it has grown in popularity, there is now more code written in Go and therefore more vulnerabilities to watch out for.
In hopes of making working securely with Go a little easier, we have pulled together a list of the top vulnerabilities in Go that developers should look out for in their products.
#1 CVE-2018-7187
CVSS v2 9.3, CVSS v3 8.8
CWE-78 OS Command Injections
We start off here with a bit of a doozy, racking up a high severity vulnerability that could lead to the leakage of data, disruption of service, or other undesirable events.
According to the write-up posted from researchers:
The “go get” implementation in Go 1.9.4, when the -insecure command-line option is used, does not validate the import path (get/vcs.go only checks for “://” anywhere in the string)
This, in turn, could “allow remote attackers to execute arbitrary OS commands via a crafted web site.”
The hackers’ ability to attack remotely is always a greater concern and is represented in the score. The fact that the victim is required to voluntarily interact with the attack mechanism is a small comfort, but still does little to diminish the effectiveness of this sort of attack.
The Fix
The solution to this vulnerability is fairly straightforward with the Go team telling users to simply upgrade to the latest version, no additional patches required.
#2 CVE-2017-15103
CVSS v2 9, CVSS v3 8.8
CWE-20 Input Validation
This vulnerability impacts the way that the Heketi 5 server API handled user requests, leaving organizations exposed to exploitation.
Another remote code execution vulnerability, exploitation here can lead to the disclosure of information, modification of data, or a disruption of service.
According to the write-up posted from researchers:
An authenticated Heketi user could send specially crafted requests to the Heketi server, resulting in remote command execution as the user running Heketi server and possibly privilege escalation.
These sorts of privilege escalation attacks allow an attacker to compromise an authenticated user and work their way up the ladder to more sensitive data. This can also be a concern for insider threats where a team member is able to gain access to data or areas that they are not allowed to.
The Fix
In response to this vulnerability being reported, the team maintaining it over at RedHat released a patch which can be accessed here.
In the commit notes, the team commented that:
It is necessary to validate the inputs before storing/using them further in the code. This patch adds validation functions to all the request structures defined in pkg/glusterfs/api/types.go . These validation functions are then provided to a validation package that can be called on a message buffer containing unmarshalled structure from JSON input.
#3 CVE-2018-16875
CVSS v2 7.8, CVSS v3 7.5
CWE-295 Improper Certificate Validation
Posing a potential denial of service (DoS) attack, this vulnerability affects Go TLS servers, including those that accept client certificates.
According to the write-up posted from researchers:
The crypto/x509 package of Go before 1.10.6 and 1.11.x before 1.11.3 does not limit the amount of work performed for each chain verification.
They go on to explain that this flaw “might allow attackers to craft pathological inputs leading to a CPU denial of service.”
The Fix
The Go team recommends that developers upgrade to the latest version, starting from 1.10.7 and upwards.
#4 CVE-2018-1002105
CVSS v2 7.5, CVSS v3 9.8
CWE-388 Error Handling
For anyone managing deployments, Google’s Kubernetes orchestration tool is probably the greatest thing since sliced bread. Having become the global standard for managing container deployments over the past few years, it was no surprise that news of this CVE sent teams into a tizzy to remediate ASAP.
This vulnerability affected all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3.
According to the write up posted from researchers:
incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection.
What makes this vulnerability additionally frightful is the fact that it is not possible to detect if it was exploited because unauthorized requests are “indistinguishable from correctly authorized and proxied requests via the Kubernetes API server.”
As Kubernetes is a Google creation, it follows that significant proportions of the code would be written in Go, making this a highly relevant CVE to have on our radar. Moving forward as Google is likely to use Go for more of their in-house creations, vulnerabilities in this language will become increasingly relevant.
The Fix
While upgrading to the most recent version will, of course, put you in the clear, there are a number of useful mitigations available on the GitHub page here that address both authorized and unauthorized attack scenarios.
#5 CVE-2016-3958
CVSS v2 7.2, CVSS v3 7.8
CWE-264 Permissions, Privileges, and Access Control
Impacting versions of Go before 1.5.4 and 1.6.x before 1.6.1, this vulnerability brings the triple threat of unauthorized disclosure of information, modification of data, and of course disruption of service.
According to the write up posted from researchers:
Untrusted search path vulnerability in Go on Windows allows local users to gain privileges via a Trojan horse DLL in the current working directory, related to use of the LoadLibrary function.
For additional info on dealing with Dynamic-Link Library (DLL) security, check out this helpful guide from the friendly folks over at Microsoft.
The Fix
Without an available workaround, the only way to secure your product is by upgrading to a safe version, ideally the latest one.
Going forward
We advise that teams take the time to track their products for any of the vulnerable versions listed above, and of course implementing fixes. As always, teams should always strive to use the latest versions which often address security concerns.
Unlike proprietary software which operates in a black box where each company needs to come up with the remediations for its own software, the open source community has built a reputation of working together to quickly produce fixes for vulnerabilities once they have been discovered. This allows developers to secure their products, leveraging the power of the crowd not only for building their products but for keeping them safe as well.
As the community of developers and companies that use Go continues to grow, we are likely to see more vulnerabilities come to light, requiring us to be attentive to reports of newly discovered vulnerabilities as they are published.
If you are interested in following more Go CVEs as well as the most pressing vulnerabilities in over 200 languages, we invite you to look for our monthly Top 5 Vulnerabilities list on our blog.
