ctf-writeups

> Can this actually manifest? Yes. Per rsc (https://research.swtch.com/gorace) > In the current Go implementations, though, there are two ways to break through these safety mechanisms. The first and more direct way is to use package unsafe, specifically unsafe.Pointer. The second, less direct way is to use a data race in a multithreaded program. That races undermine memory safety in go has been used in CTFs: https://github.com/netanel01/ctf-writeups/blob/master/google... These are not idle fancies, there are lots of ways to unwittingly get data races in go: https://www.uber.com/blog/data-race-patterns-in-go.

Several of our clients have Go codebases. My general experience as a security auditor of Go projects has been that it is mostly akin to security auditing of Python projects (I'd say it's like Java auditing, but I'm very concerned/excited about deserialization bugs in Java programs and am not so optimistic about finding them in Go programs). Which is to say, the low hanging fruit won't be exploitable type safety problems, but rather application logic issues: SQL injection (Go's database integration is still the wild west), failure to properly authorize RPCs or HTTP endpoints, SSRF, and stuff like that. I'm probably not going to use property testing to find an SSRF, or to spot a static nonce, or something like that (somebody feel free to put me my place over that! maybe I should use more property testing!) It's interesting that the strateg