Compile audit areas

[moul]

The goal is to create a list of audit areas to effectively plan our auditing strategy.

@kristovatlas will lead this task, and we will need input from the @gnolang/core-contributors as well as suggestions from outside contributors. We should include new areas specific to this repo and link to known areas from the original fork.

[thehowl]

for what concerns the VM, there is a lot to cover. here are some ideas

• first, we have the DoS attacks similar to Two critical VM issues (denial of service attacks) #2738 or test(bug): txtar to reproduce the VM hanging during Render #1736. in general, we need to take a look at the entire package (pkg/gnolang) to find all kinds of places where we're accepting user input from the gno program and running "without limitations", ie. on the max vm cycles or the gas.
• realm storage, and interaction of the GnoVM with the gno.land chain.
  • example problem: if I do a MsgRun, are the references to any values created within stored as references to the values of gno.land/r/<address>/run? is it possible right now to store one value and "swap it" with another one on a subsequent execution of MsgRun?
  • example problem: is it possible, to create any kind of cyclical structure, that when saving it or re-loading a realm's state after restart, causes an infinite loop?
• gno programming, and standard libraries.
  • is it possible for a realm in any way to impersonate an end-user?
• VM "validity" bugs.
  • before we introduced type checking and terminating statement analysis, it used to be possible to have a function which didn't have a return statement, which would lead to its values on the Machine.Values stack not being popped. Are there any other places where malicious code could "swap" the value of a variable or a function?

it may be useful to use this to "classify" the kind of security problems that can arise out of the VM, which will have different impacts (ie. on the chain stability, or on the safety of the language).

we need to treat all code coming into pkg/gnolang as potentially unsafe; and try to "break" all of its components, from the preprocessor to the execution to the realm storage.

hopefully that gives a few places where to start. by my estimation, we should have probably a dozen vulnerabilities which are low hanging fruit, and an almost infinite amount of insidious vulnerabilities, as IMO understanding the VM is complex if you don't live in Jae's brain, and how its parts interact is non-trivial, so there's definitely a lot of things we missed when merging even after doing the careful reviews we carry out.

[kristovatlas]

We are starting to annotate files and directories in terms of auditing scope here:

https://docs.google.com/spreadsheets/d/1rAvzvCH1TBZAykWCzKpefJnbx0SaCEgnP6IypzX8Xo4/edit?usp=sharing

(All members of public currently can comment and propose changes to the doc.)

A few Gno contributors had a call on this topic earlier and I'll post the meeting notes shortly..