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.

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.