
Security assessment techniques for Go projects - ngaut
https://blog.trailofbits.com/2019/11/07/attacking-go-vr-ttps/
======
tptacek
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 strategies described in this post lean so heavily on
theoretical program correctness; as I read it, it felt super useful to me as a
Go developer, and less directly applicable to my assessment work.

Relatedly, this post was circulating on Twitter yesterday, and it is great: a
race condition in Go code exploitable for RCE:

[https://github.com/netanel01/ctf-
writeups/blob/master/google...](https://github.com/netanel01/ctf-
writeups/blob/master/googlectf/2019/pwn_gomium/README.md)

I probably had your attention with that summary! Race conditions in Go code
could be a broadly exploitable bug class! Except: not so much, no: the
conditions making that bug exploitable are both contrived and outlandish
enough that no security reviewer, even one unfamiliar with Go, would have been
comfortable with that design.

~~~
sethammons
> SQL injection (Go's database integration is still the wild west)

Could you elaborate on this? I thought you were safe if you used the '?'
parameter replacement.

~~~
tptacek
Oh, you are, to the extent that you are when you directly use parameterized
queries anywhere (ie, there are corner cases). But unlike Java-world and
Python-world and Ruby-world, there aren't really idiomatic mainstream
heavyweight database interfaces in Go-world, so if your application is
dynamically composing its own SQL queries, which many serious applications end
up doing, you can end up with concatenated SQL and the attendant bugs.

I'm not going to go into a fresh Django project optimistic about my chances of
finding SQLI, but a database-heavy Go program, that's one of the first things
I'm going to take a whack at.

~~~
SEJeff
You don't think gorm is mainstream? It isn't the only choice, but is used
pretty extensively.

~~~
tptacek
I'm familiar with gorm, but haven't seen it at any of our clients.

~~~
SEJeff
Fair, perhaps we can fix that with an audit soonish :)

------
ngaut
There is another implementation of failpoints for Golang. Which is used by
TiDB. See more details:
[https://github.com/pingcap/failpoint](https://github.com/pingcap/failpoint)

------
DaniloDias
If Go has memory management, what does fuzzing Go applications yield in terms
of security defects other than D.o.S. crashes?

