Universal Go exploit using data races, no imports

In the last two blog posts, I described a challenge and exploits to get code execution from arbitrary Go code only allowing the fmt package, at fixed Go version 1.13.3 and without PIE.

These factors made the challenge easier for a CTF: the fmt package gives a nice leak with %p, no pie and fixed Go version 1.13.3 allows to hardcode addresses and behave deterministically with code layout, heap, compiler optimizations and calling convention.

Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes! It's been sitting in my exploits folder for long enough that it's time to write about it.

The Gomium Browser - Exploits

In my last blog post, I described The Gomium Browser, a pwn challenge of the Google CTF 2019 finals that 4 teams (pasten, 5BC, p4, A*0*E) solved.

The challenge was framed as a command-line browser, but basically boiled down to answering this question: if you control Go source code but can only import the fmt package, can you get enough code execution to execute xcalc?

In this blog post let's look at some of the exploits that teams came up with, either during the CTF or after.

Golang data races to break memory safety

Go is becoming more and more popular as a programming language and getting more scrutiny from a security point of view. You might remember my heap corruption during garbage collection post. A few days ago Scott Piper wrote Looking for security trouble spots in Go code, an interesting read.

I'd like to expand on a topic I've researched a few months ago after discussing with Dmitry Vyukov (ASAN, TSAN, core Go contributor). He mentioned once on the public Go mailing list that you can break the memory safety of Go with data races, and it piqued my interest so we'll explore that in this post with some exploits.

Before I start, it's important to realize that the Go team knows about this: see Russ Cox detailed blog post Off to the Races.

Golang heap corruption during garbage collection

I've been playing with Go recently, it's an interesting programming language (I recommend the tour).

It is compiled, garbage-collected and memory safe.. as long as you don't find a bug in the runtime. Alex Reece (@awreece) from PPP recently blogged about a nice vulnerability, I found it interesting and started following more of the changes.

This one looked fun: runtime: fix heap corruption during GC (#5554), let's try to exploit it. The bug was not present in Go 1.0.3, present in Go 1.1 but will be fixed in Go 1.1.1 (to be released next week).