Looking for security trouble spots in Go code

This is a creation in Article, where the information may have evolved or changed.

Different languages has certain areas where mistakes is commonly made, and which code auditors focus on. With C, you might grep for strcpy and memcpy . With Ruby, you might the look for regex, the use ^ and $ instead of \a and \z. The use of those functions or idioms is not always vulnerabilities, but is good places to check first. I decided to look for such trouble spots for Go (Golang). Idid not find any.

Go have a lot going for it in terms of the security, such as no pointer arithmetic, no manual memory management, a standard Lib Rary that seems fairly well thought out and purposefully excludes things that is misused (ex. no ECB mode for AES), and P UT together by a team of seasoned veterans. However, one must also consider that part of the reason it does not having known trouble spots is perhaps due to it being SU CH A young language The it had not had time for a lot of mistakes to pile up, or for it to being misused in unexpected ways.

With this, let's look at some issues that has been found.

Update 2014.04.15: The initial post of this article stated go get defaults to HTTP, but have been corrected to state it falls back to HTTP .

Fixed issues

cve-2014-7189

The Go runtime has have only one CVE, cve-2014-7189, which is introduced in Go 1.1 and fixed with Go 1.3.2 on 9/25/2014. This vuln were relevant to client certificates, which are not a common thing to does, although you can find a example here's Using Go with client certs. The vulnerability is described as "If the server enables TLS client authentication using certificates (this is rare) and E xplicitly sets Sessionticketsdisabled to true in the TLS. Config, then a malicious client can falsely asserts ownership of any client certificate it wishes. "

RCE on play.golang.org

In, Alex Reece of the Plaid Parliament of pwning (PPP) wrote about exploiting a Go Binary wherein Geohot were able to Write Go code that would give a arbitrary write in memory, allowing for Remote code Execution (RCE). This is a useful in cases where can get someone to compile and run Go code of your choosing, given that restriction , this was much like Java client exploits on browsers, but there was no Golang browser plugins, so this could only really B E used on play.golang.org or Google App engine. Unless you is receiving and running arbitrary Go Code, you don ' t need to worry much about problems like this. This appears to has been fixed.

Bug bounties

The only bug bounty I know to Go code, is Ethereum's bug bounty for their client. The description of Ethereum is a jumble of buzzwords such as "Web 3.0" and "Turing complete cryptocurrency", but for our D Iscussion we don ' t need to know, what's it is.

One bug bounty awarded is for a out of bounds read. These would only cause crashes on Go, so it's a just a DoS, and not that interesting.

More interesting is the other bounties. One is for using a signed int and expecting it is used with values greater than zero. This allowed for manipulation and abuse of a important value. Although not used in the this case, it's important to point out integer overflows does not cause any exceptions in Go and would Wraparound. Most languages does not throw the exceptions, but are possible in C # (there is a project setting to check for this). Also, the size of a int in Go was dependent on the processor, so the following code may has different outputs depending On the system architecture:

variint=2147483647i+=1                fmt.Println(i)         // Prints -2147483648 or 2147483648

The other is an issue related to misuse of Crypto wherein a nonce (should be a random number) is generated by xor ' ing th e private key with the message, thereby leaking information about the private key. Oddly, the founder of that project actually forked and modified a library in order to implement this questionable change. The finder of these bugs was awarded 10BTC, about $2300. Neither of these issues is specific to Go.

unfixed issues

No ASLR

Part of the reason the RCE vulnerability mentioned previously were possible is so Go binaries is not compiled with th E standard protections such as ASLR, and on Windows it additionally lacks DEP. This is also discussed by the PPP in a post from, titled Securing and Exploiting Go Binaries. It appears for ELF binaries the stack is no longer executable. For demonstration purposes, it is shown a vulnerable C library, when linked to Go application, does not has the SEC Urity mitigations normally in place for modern compiled code. The danger of not had this means so if you had a library that had a memory corruption vulnerability, often these MIT Igations'll make the vulnerability unexploitable, or only probabilistically exploitable. Although Go itself may is not having these memory corruption vulnerabilities, they should still take these precautions since PE Ople sometimes may link against non-go libraries.

As an example, Don A. Bailey of Lab Mouse Security found such A vulnerability in A Real library (the LZ4 compression libra RY) which was interfaced with via a Golang the library (GOLZ4) from Cloudflare and wrote on his exploitation of it.

We should not expect ASLR to is added any time soon, because in a discussion about this, Russ Cox (who works on the Go run Time) commented:

"Address space randomization is an os-level workaround for a language-level problem, namely that simple C programs tend to Be full of exploitable buffer overflows. Go fixes the language level, with bounds-checked arrays and slices and no dangling pointers, which makes the Os-le Vel workaround much less important. In return, we receive the incredible debuggability of deterministic address space layout. I would not give this up lightly. "

Go get falls back to HTTP

Dmitry Chestnykh opened an issue on go get the command, which is used to download libaries, would fall back to up USI Ng http, unless the files is downloaded from github.com, code.google.com, bitbucket.org, launchpad.net, or Jazzhub (HUB.J Azz.net/git). The threat here's that developers could was MiTM ' d so this access to HTTPS was blocked, causing the to fall back to go get H TTP, allowing for the files to be manipulated. This isn't so much a language problem and something to be aware of.

Conclusion

Unless you is using compiled libraries (derived from C code or other languages this aren ' t memory safe), you are safe fro M buffer overflows, use-after-free ' s, and other memory safety bug classes. This still leaves the whole OWASP Top 10. However, there is not known trouble spots on Go code from a security perspective.

To don't leave you completely empty-handed, if you is auditing Web server code, some simple things your should check for IS :

• CSRF Protection via the Nosurf library.
• XSS mitigation via HTTP headers via the Unrolled/secure library.
• Secure Session management via gorilla/sessions which would result in a call to sessions.NewCookieStore([]byte("something-very-secret")) . Make sure something random and secret are used for that byte array, as it would be used in an HMAC (using SHA256) to protect The cookie is from tampering.