w3f-grants-archive/web3-grant

web3-grant

Scout: Security Analysis Tool

We worked on three deliverables as committed in the proposal towards the aim of building extensible open-source set of tools to assist ink! smart contract developers in the detection of security issues. These deliverables are:

1. A curated list of ink! Vulnerabilities.
2. A set of smart contracts written in ink! including the above vulnerabilities, and
3. Proof-of-concept tools detecting the vulnerabilities in these smart contracts

In short, we worked to have a list of relevant vulnerabilities that represents the security issues that can be found in ink! smart contracts. This list is not intended to be exhaustive nor ordered by any other criteria. We then worked in finding (small) smart contracts with these vulnerabilities, often introducing ourselves the vulnerabilities by modifying a seemingly-safe contract. Finally, we selected a set of static/dynamic analysis tools that are effective in analyzing Rust code, which are also open source, well maintained, and (more importantly) can be used to detect vulnerabilities in ink! smart contracts. We went to implement detectors for all the vulnerabilities we had compiled, sometimes having more than one detector (tool) for a vulnerability. These tools/detectors are checked to have a quality consistent with a proof-of-concept and are probably not product-ready.

The table below summarizes how the three deliverables relate to each other. In each row there is a vulnerability class, a smart contract which exposes a vulnerability in that class, and one or more detectors which detect instances of the vulnerability class and the example smart contract in particular. Details follow in the folder/repo for each deliverable (1, 2, and 3).

During our research we also found some relevant information which is tangent to this project, yet we could use it to weight the curated list of vulnerabilities ([1]).

We end this document with a Future Work section where we discuss how could we follow up on this work.

Detectors

Detector ID	Category	Description	Severity
integer-overflow-or-underflow	Arithmetic	An arithmetic operation overflows or underflows the available memory allocated to the variable.	Critical
set-contract-storage	Authorization	Insufficient access control on set_contract_storage() function.	Critical
reentrancy	Reentrancy	Consistency of contract state under recursive calls.	Critical
panic-error	Validations and error handling	Code panics on error instead of using descriptive enum.	Enhancement
unused-return-enum	Validations and error handling	Return enum from a function is not completely used.	Minor
dos-unbounded-operation	Denial of Service	DoS due to unbounded operation.	Medium
dos-unexpected-revert-with-vector	Denial of Service	DoS due to improper storage.	Medium

Future Work

In the month this project lasted we had limited time to develop vulnerable smart contracts, learn how to build detectors for these vulnerabilities using the selected tools (dylint, semgrep & cargo-fuzz). The precision of the tool set we have built should be analyzed, and the detectors tuned to improve precision and recall. This amounts to compiling a larger set of smart contracts, vulnerable and not, and having the detectors detect vulnerabilities effectively while not generating false positives.

This can be attained by different means. As there is not a large size of security audit reports available for public ink! smart contracts, or any other means to quickly obtain realistic smart contracts that include vulnerabilities and these vulnerabilities have been identified, there is a need to obtain an annotated base of vulnerable smart contracts. With this in hand, one can determine the quality of a vulnerability detection tool. We suggest that spending time in analyzing the ink! smart contracts that are being deployed with our toolset and also via a manual/assisted audit process. Hence, we would cerate this annotated database and then find false positives, false negatives, true positives (and true negatives) for our toolset and work on adding detectors or tuning the existing ones in order to improve the overall precision and recall. Integrating the tools into a single prototype and making it available to ink! developers would also help the community in finding bugs and us builders in improving the tool. A beta test with a small set of developers, using the tool and delivering feedback would be the final test outside the laboratory.

Then we would turn this prototype into a robust product-quality tool, integrated with IDEs, and improve its documentation accordingly.