Identifying Vulnerabilities in Smart Contracts
using Interval Analysis

The Solidity statements assert and require are typically used to validate boolean conditions. According to the Solidity documentation⁶⁶6Solidity docs: https://docs.soliditylang.org/en/v0.8.20/control-structures.html, assert is meant for checking internal errors, while require should be used to test conditions that cannot be determined until runtime. Both statements throw exceptions and revert the corresponding transactions. In their intended use, the conditions in assert should never be false as it signals contract level errors while the conditions in require can be false as they signal input errors. No matter what level of error a statement specifies, it is an issue if the conditions that they contain are tautologies or contradictions. These make the statement useless in the case of tautologies and make the transaction impossible to complete in the case of contradictions as illustrated by the following code:

1:  function notGonnaExecute(uint parameter) external pure returns(uint)
2:  {
3:      require(parameter<0); // uint cannot be < 0
4:      return parameter;
5:  }

1:  function uselessAssertUint(uint parameter) external pure returns(uint)
2:  {
3:      require(parameter>=0); // uint is always >= 0
4:      return parameter;
5:  }

This is a classic arithmetic issue that is common among most programming languages. The Solidity compiler does not allow direct division by zero. However, the compiler cannot detect situations when the denominator could evaluate to zero. The following code snippet contains an example. The length of the recipients array is not checked before computing the amount that should be sent to each recipient (line 4):

1:  function split(address[] calldata recipients) external payable
2:  {
3:      require(msg.value > 0,"Please provide currency to be split among recipients");
4:      uint amount = msg.value / recipients.length; // problem here if length is 0
5:      for(uint index = 0; index < recipients.length; index++)
6:      {
7:          (bool success,) = payable(recipients[index]).callvalue:amount("");
8:          require(success,"Could not send ether to recipient");
9:      }
10: }

This is another arithmetic issue that is common among many programming languages. Solidity performs integer division which means that the result of the division operation is truncated. This could lead to situations where ignoring the remainder of the division could lead to logic errors. The snippet below contains an example: if the provided amount does not exactly divide by the number of recipients then that amount of cryptocurrency could remain locked in the contract.

1:  function split(address[] calldata recipients) external payable
2:  {
3:       require(recipients.length > 0,"Empty recipients list");
4:       uint amountPerRecipient = msg.value / recipients.length; // remainder ???
5:       require(amountPerRecipient > 0,"Amount must be positive");
6:       for(uint index = 0; index < recipients.length; index++)
7:       {
8:           payable(recipients[index]).transfer(amountPerRecipient);
9:       }
10:  }

Uninitialized variables could lead to logical errors or exceptions. If a variable is not initialised, there is a great chance that the default value assigned to the variable (according to its type) is not suitable for the purpose of that variable. The following code contains an access modifier which relies on the owner state variable. The variable is private, and thus, it cannot be accessed or assigned outside the contract. Also, there is no explicit initialisation of owner within a constructor. This makes the variable stuck to the default value, and thus, all the functions marked with the onlyOwner modifier cannot be executed.

1:    address private owner;
2:
3:    modifier onlyOwner() {
4:        require(msg.sender == owner, "Only the owner of the contract has access");
5:        _;
6:    }

Parameter validation or “sanitisation” is a process that must be implemented at the beginning of every method. This ensures that the method will always execute as expected. End users should not be trusted to always provide valid parameters. If validation is missing and the end user is unaware, or worse, malicious, it could cause critical errors that produce unexpected results or halt contract execution all together. The following example contains a getter method for an internal array. The user can provide an index that is not validated, thus having the possibility of going out of bounds.

1:    uint256[] private _array= [10, 20, 30, 40, 50];
2:
3:    function getArrayElement(uint256 index) external view returns (uint256)
4:    {
5:        return _array[index];
6:    }

In Solidity, enums are stored as unsigned integers. Thus, they can be compared and assigned with variables of type uint. Situations like these can become tricky since the value domain of an enum is likely to be much smaller than the value domain of unsigned integers. If a variable with a greater value than the range of the enum is assigned to an enum variable, than the transaction will be reverted. While it is true that reverting the transaction is considered safe, such situations signal a faulty logic in the contract code and it is preferable to be avoided.

1:  contract UnmatchedType {
2:      enum Options { Candidate1, Candidate2, Candidate3 }
3:      mapping(address => Options) private _votes;
4:      mapping(Options => uint) private _votesCount;
5:      function vote(uint option) external {
6:          _votes[msg.sender] = Options(option);
7:          _votesCount[Options(option)]++;
8:      }
9:      function getStatisticsForOption(uint option) external view returns(uint) {
10:         return _votesCount[Options(option)];
11:     }
12: }

Interval Analysis [9] is a static analysis technique that approximates the values interval for every variable in a program for a certain instruction. The technique is not limited to predicting the values interval of a variable, it can also be used to predict certain properties that can be derived from the value of the variable. For instance, instead of working with integer intervals, an analysis can target the parity of variables and work only with 2-valued intervals (even, odd).

We present interval analysis via the Unmatched Type example from Section 2.6. Moreover, we show how interval analysis can help us detect a problem in this example, more precisely in the vote function:

5:      function vote(uint option) external {
6:          _votes[msg.sender] = Options(option); //Statement 1
7:          _votesCount[Options(option)]++;       //Statement 2
8:      }

Interval analysis provides an approximation of the values interval for every program variable at each program location. In Table 2 we show how these intervals are computed for our example. Each line of the table presents the intervals for the program variables (displayed in columns) before the execution of each statement in the first column. For example, before the execution of Statement 1, we do not have any information about the option variable, so its range of values will correspond to the values domain for uint. For _votes[msg.sender], the value interval changes before Statement 2 in case of normal execution (otherwise, the transaction is reverted) to [0,2], that is, the only possible range for Option. Interval analysis performs this calculation using the Worklist Algorithm, an algorithm which traverses the program control flow graph, and updates the intervals for these variables until a fixpoint is reached. This algorithm is shown in Section 4.2.

Recall that the problem we are trying to detect using interval analysis is a mismatch of domains between the variable assigned and the variable whose value is assigned. Since interval analysis computes the interval for option and _votes[msg.sender], a close inspection of the difference between the intervals is sufficient to reveal the problem. A require statement that checks upfront the values for the option parameter would solve the problem. Also, our detection technique would not signal an issue.

We built our implementation using Python modules provided by Slither. These are the same modules that are used internally by Slither for its own detectors. During execution, Slither fills some of its internal data structures with useful information, such as contract CFG (control flow graph), an intermediary SSA (single statement assignment) representation of the code, and information about each variable (e.g., type, scope and name). We use the information in these data structures to implement interval analysis.

The Worklist Algorithm shown in Figure 1 works by processing every edge in the contract CFG. These edges are added into a list (the ”worklist”). It is an iterative algorithm that processes existing elements until the list is empty. When new information is added to the current state, new edges are also added to the worklist. The algorithm stops when no more new information can be discovered.

We implemented a modular Worklist algorithm. Essential information such as extreme labels⁸⁸8The program nodes where the analysis begins., order function⁹⁹9A function that receives two elements of the same domain and determines the greater one. and flow function¹⁰¹⁰10A function determining the edges in the flow graph or the reverse of those edges depending on the type of analysis. are all provided as parameters to the Worklist algorithm. This allow us to perform multiple types of analysis using the same base implementation. Our implementation leverages the CFG provided by Slither to split the code of a function into multiple parts. Each node is then split even further into SlithIR SSA [3]lines that are analyzed individually. Along with basic types such as uint and bool, our implementation is able to model complex types such as arrays, mappings and structs.

We defined our own data type to encapsulate information about a variable such as type, scope, name and, most importantly, values interval. The program state is represented as a dictionary having variable names as keys and an object of our own defined type as values. Complex types are defined as recursive dictionaries, for example, the interval for a struct is modeled as a dictionary containing intervals for each of its fields or even other dictionaries if the structs are nested.

We are now handling only on a subset of expressions in the Solidity programming language, which covers expressions including integers, booleans, arrays, structures, and mappings. However, more elaborate work needs to be done to tackle addresses and operations over addresses, more complex loops or conditional statements, etc. Right now, our code can be executed on every smart contract written in Solidity, but it will perform interval analysis only for the subset that we cover.

Intraprocedural analysis would significantly improve the precision of our analysis. An example of a vulnerability that we are not yet able to detect is Short Address. This could be detected by monitoring the length attribute of the payload. Another example is Tautologies and Contradictions in Assert or Require Statements: it could be detected by approximating the result of the boolean expression and checking if the interval contains only one value: true for tautologies and false for contradictions.

Being able to handle more complex conditional statements and loops would also be of great help in obtaining a more accurate monitoring of the program state by interpreting the semantics of boolean expressions. Once we identify multiple possible states based on conditional branches, we can leverage unifying techniques such as Trace Partitioning. Additionally, monitoring implicit state variables that are contract-level or function-level, like balance or msg.sender, would be beneficial in identifying balance-related issues and user interaction problems.