Making Smart Contracts Smarter Authors Loi Luu Duchiep

Making Smart Contracts Smarter Authors: Loi Luu, Duc-hiep Chu, Hrishi Olickel, Prateek Saxena, Aquinas Hobor Presenter: Kendric Hood

Contribution This paper Identifies several security exploits in the Ethereum Cryptocurrency Smart Contracts and provides a way to identify them prior to submission to the blockchain.

Smart Contracts A Smart Contract is a procedure that is executed by the miners and its correctness maintained by the blockchain consensus. Many cryptocurrency’s have them with varying implantations. This paper only focus on Ethereum’s implantation. Smart Contracts is made up of three main parts 1. Address of the contract 2. EVM Bytecode (logic of the contract) 3. Storage Invoked by sending ether to the Address of the contract When the transaction is accepted on the block chain the bytecode is excited

Gas is the mechanize in Ethereum to prevent a contract from wasting miner resources. Gas Price: is the amount of gas that is needed to run some line of code Gas Cost: is the amount of Ether needed for each unit of gas Never used outside of the localhost, when a user invokes a contract they must send a certain amount of Ether to pay for the gas cost. If more gas is used then is paid for then the execution of the contract is stopped. Spent Ether is not refunded.

Vulnerability's There are four types of Vulnerability’s identified 1. Transaction Ordering Dependence (TOD) 2. 3. Timestamp Dependence Mishandled Exception 4. Reentrancy

Transaction Ordering Dependence This is an issue where the order in which transaction are executed effects the final outcome of a contract. An example would be the Puzzle Contract If the owner attempts to change the reward amount at the same time as the solution to the puzzle is submitted the reward amount can change based on which is executed first.

Timestamp Dependence are contracts which use the block timestamp. The Run is one example where the block timestamp is used to determine the winner. A miner can manipulate this time stamp to his/her favor.

Mishandled Exception A mishandled exception is an issue with the way that Ethereum has implemented the << send >> instruction. Known exploit is to force a contract to raise an exception by causing a stack overflow

Reentrancy is when a contract calls another contract and is left in an intermediate state. For example if a user tries to use a contract to withdraw Ether from some account the account value might only be updated after the Ether has been sent via a different function however if this function calls to withdraw the balance again then more ether will be withdrawn because the account was not updated.

Solutions Update the clients on all miners Test contracts with the Oyente Tool before deployment

Updates to Miners TOD Add a guard condition, for example if submitting a solution to the Puzzle contract the guard condition would verify that the reward is the same as when the solution was posted. If not then the solution is not submitted. This is very similar to the compare and swap instruction supported by most processors. Current contract can be maintained by simply passing True for the guard condition by default.

Updates to Miners Timestamp Dependence can be fixed by using the block index instead. The index can not be changed by the miner and is available to all miners. Current contracts can be maintained by changing the << TIMESTAMP >> instruction to return the block ID instead.

Mishandled Exception Update the EVM to propagate exception as most modern languages do.

The Oyente Tool can be used to evaluate contract before they are submitted to the block chain. The Oyente Tool identifies Bugs and Security risks in a contract.

The Oyente Tool cont. Reads in the EVM bytecode can the current Global Ethereum State Oyente simulates the EVM by symbolic execution of the contract. Each value of the contract is replaced by a symbol. These symbols are then used later to determine which path of the CFG is taken Identifies all four attacks outlined before

CFG Builder The CFG Builder constructs a control flow graph where each state is a node and there transitions are the edges between them Not all edge are known at the time the CFG builder builds the Graph and so more added/removed on the fly during the symbolic execution.

Explorer The Explorer starts from the entry node of the CFG. The Explorer then runs an instruction under every possible state the contract might be in. It then uses a solver (Z 3) to check if a branch is provable True or False, that is will this instruction always lead to one particular instruction or does the path split. If a path is provable True or False the only one path is explored otherwise all possible paths are explored.

Core Analysis Once the CFG is built and then updated by the explore all posable path of Ether are check for the attacks outlined before. TOD: Explorer will highlight paths that can results in deferent Ether flows on swapping transaction orders. Timestamp dependence: Simply highlights when timestamp is used in the contract Mishandled Exceptions: Checks if a contract check for exceptions in other contracts/function it calls, by looking for ISZERO operator on the operator stack Reentrancy: At each CALL statement a check is preformed on the path condition to see if the CALL can be made again, if so such a vulnerability exsits

Validation Attempts to remove some false positives by checking conditions flagged by the core analysis. Each condition is checked for feasibility, if such a path is infeasible then it is removed from the list of flagged vulnerabilities.

Evaluation Oyente Was run on 19, 366 contracts Total amount of Ether was 3, 068, 654 About 30 Million Dollars Most contract had a balance of zero 10% had at lest one Ether While one contract had 38. 9% of the total Average was 318. 5

Evaluation cont. To verify Oyente Accuracy contracts had to checked manually. Of the Mishandled Exceptions 116 of 1, 385 where checked (8%) 100% Accuracy TOD Dependence 32 of 135 checked (24%) 72% Accuracy Timestamp Dependence This requires there source to be publicly available 7 of 52 checked (14%) Reentrancy Handling 2 of 186 checked (1%) 100% Accuracy

Thoughts Oyente seems to be very useful but Why not find a way to update contract? The vulnerabilities seem to have simple solutions Oyente seems under utilized for solving this problem A far amount of the paper us used on describing the vulnerabilities but for the most part they are known vulnerabilities, not first introduced by this paper. More time should have been spent on Evaluation.