enumerate risky calls in Go and verify they are not available in Gno

[kristovatlas]

Description

Various Go standard library functions can create negative consequences for the systems that they are executed on. We should document these and verify that they are not available in Gno. It's unlikely that this would be the case, but it should be documented as an obvious thing to check, anyway.

[kristovatlas]

To investigate this issue, I generated a list of 72 functions in the Go standard library that could be used maliciously if executed on someone else's machine.

dangerous-go-functions.csv

It's a little tricky to discern from source code whether a Go standard library function is available in Gno. We have this doc:

https://docs.gno.land/reference/go-gno-compatibility/#stdlibs

However, this list is misleading in some contexts; for example, you can access os.Stdout from the gno run interpreter even though the category for the "os" package in the list above is "non-determinstic".

Also, you can't just look at the gnovm/stdlibs directory. For example, there's no "os" file or directory there but you can access os.Stdout from the gno run interpreter.

To be more complete, I wrote a script that attempts to import all of the danger packages in Gno code deployed to a local blockchain:
https://gist.github.com/kristovatlas/45ce8f63e99a8e3f0990eecd559175a2

This ruled out most of the 72 risky functions, and after checking the last few remaining with manually created gno files, only these functions are actually accessible on-chain:

• io.Copy
• strings.Replace

These aren't inherently dangerous functions like exec.Command, but the following issues could arise:

io.Copy

• unrestricted file or network access: Ostensibly not possible as relevant packages are not supported
• DoS: I attempted some memory consumption exploits but they resulted in Data: allocation limit exceeded error when called on-chain
• data leakage: can't can get any data that's beyond the Gno context, should should be ok
• ACE when used with system-level streams: system-level streams shouldn't be accessible

strings.Replace

• command injection: exec stuff not accessible
• file manipulations: file stuff not accessible

I consider this topic sufficiently researched for now.