Returned interface{} types may be a worthwhile place to begin an audit. Crashes are found at runtime, so if you can identify normally-unlikely-yet-still-possible paths you can often trigger crashes that the authors didn’t hit in testing, and users didn’t hit yet in production. I’m curious about the semantics of a panic and if there are any interesting race conditions you can pry into in the runtime immediately after something has triggered one from another goroutine.
I think one of the most interesting places to look for security trouble spots is actually in non-go code. Go apparently doesn’t use ASLR, which is fine for go code, but means that C libraries linked in using cgo don’t have ASLR enabled, which could make some C bugs much easier to exploit in go processes.
It’s pretty rare that ASLR will outright prevent exploitation though. It makes it harder, but if a library has a security flaw when linked without ASLR then it the same bug is probably still a security flaw when linked with ASLR.
Returned interface{} types may be a worthwhile place to begin an audit. Crashes are found at runtime, so if you can identify normally-unlikely-yet-still-possible paths you can often trigger crashes that the authors didn’t hit in testing, and users didn’t hit yet in production. I’m curious about the semantics of a panic and if there are any interesting race conditions you can pry into in the runtime immediately after something has triggered one from another goroutine.
I think one of the most interesting places to look for security trouble spots is actually in non-go code. Go apparently doesn’t use ASLR, which is fine for go code, but means that C libraries linked in using cgo don’t have ASLR enabled, which could make some C bugs much easier to exploit in go processes.
It’s pretty rare that ASLR will outright prevent exploitation though. It makes it harder, but if a library has a security flaw when linked without ASLR then it the same bug is probably still a security flaw when linked with ASLR.