Smart Contract Security

However, the trustworthiness of execution does not prevent or mitigate the occurrence of software bugs and vulnerabilities in smart contracts. Risks posed by smart contract vulnerabilities are exacerbated by the typical design of blockchain based platforms, which does not allow the code of a contract to be updated (e.g., to fix a vulnerability) or a malicious transaction to be reverted. In practice, a significant number of contracts suffer from software vulnerabilities, as illustrated by a recent automated analysis of contracts that are deployed on the public Ethereum blockchain. The report found that 8,333 out of 19,336 contracts suffer from at least one security issue. While not all of these issues lead to security vulnerabilities, some of them enable stealing cryptocurrencies and other digital assets. For example, $50 million worth of cryptocurrency was stolen in the “DAO attack”, and $280 million worth of cryptocurrency was lost in the 2017 hack of the multisignature Parity Wallet library.

Contract vulnerabilities are often introduced due to the semantic gap between the assumptions that contract developers make about the underlying execution semantics and the actual semantics of smart contracts. For example, the syntax of Solidity, the most widely used high-level language for developing Ethereum contracts, resembles JavaScript, but its semantics are quite peculiar. As a result, developers who are not familiar with the intricacies of smart contract development tend to make common mistakes, which result in security vulnerabilities. Below, we discuss some of the most common types of vulnerabilities.

Common Vulnerability Types in Ethereum smart contracts

Motivated by a large number of smart-contract vulnerabilities, many researchers have provided surveys and taxonomies of common vulnerability types [1]. Here, we list some of the most typical vulnerabilities in Ethereum smart contracts, focusing on Solidity.

Re-Entrancy

Re-entrancy is one of the most well-known culprits behind contract vulnerabilities. On Ethereum, when a contract calls a function in another contract, the execution of the caller is blocked until the call returns. This allows the callee, who may be malicious, to take advantage of the intermediate state in which the caller is, e.g., by invoking a function in the caller. For example, in a cryptocurrency-withdrawal transaction, a malicious callee may be able to initiate another withdrawal before the caller decreases its balance. A similar re-entrancy vulnerability was exploited in the infamous “The DAO” attack.

Transaction-Ordering Dependence

If multiple users invoke functions in the same contract, the order in which their calls are executed cannot be predicted. As a result, users have uncertain knowledge of the state in which a contract will be when their calls are executed. For example, in a contract that implements an online marketplace, one user might be able to change the price of an item before another user’s purchasing transaction is executed.

“Denial of Service”

If a function involves sending ether using transfer or making a high-level function call to another contract, then the recipient contract can “block” the execution of this function by always throwing an exception.

Deadlock

A contract may end up in a “deadlock” state (either accidentally or through adversarial action), in which it is no longer possible to withdraw or transfer currency from the contract. This means that the currency stored in the contract is practically lost, similar to what happened to the Parity multisignature wallet contracts.

Timestamp Dependence

In Ethereum, a malicious miner can alter the clock that is used in the execution of smart contracts by several minutes. More specifically, a miner can choose the timestamp of a block arbitrarily, but other miners will accept the block only if its timestamp is within a certain range of their clocks. As result, contracts whose correctness depends on the accuracy of the clock may be vulnerable. For example, a contract that uses the clock for generating random numbers may be exploited by a miner who chooses the block timestamp to generate the random number in its favor.

Mishandled Exceptions

Depending on how a function is called, an exception in the callee may or may not be propagated to the caller. Due to the inconsistency of the propagation policy, developers can quickly forget to properly handle exceptions in callee contracts.

Contract Verification and Smart Contract Security Tools

To find and patch contract vulnerabilities before deployment, developers can employ contract verification and vulnerability discovery tools [2].

• Oyente is a smart contract security analyzer for Ethereum contracts that can detect certain typical security vulnerabilities.
• Securify is a security analyzer for Ethereum contracts, which symbolically encodes the dependence graph of a contract in stratified Datalog and then uses off-the-shelf solvers to check the satisfaction of desired properties.
• EthIR is an analysis tool built on Oyente, which builds control-flow graphs of Ethereum bytecode and uses it to search for vulnerabilities. EthIR generates a high-level, rule-based representation of contract, which enables the application of existing analysis to infer properties.
• MAIAN is a tool for the automatic detection of three types of vulnerable contracts, called prodigal, suicidal, and greedy, by analyzing Ethereum bytecode.
• Vandal is a security analysis framework for Ethereum smart contracts, which converts EVM bytecode to semantic relations, which are then analyzed to detect vulnerabilities described in the Soufflé language.
• Mythril is a smart contract security analysis tool for Ethereum smart contracts with a symbolic execution backend.

Besides contract verification and vulnerability discovery, developers may also use correct-by-design frameworks and runtime verification.

• VeriSolid is a framework for the correct-by-design development of Ethereum smart contracts. VeriSolid allows developers to specify contracts using a transition-system based model with rigorous semantics, supported by an open-source, web-based, graphical IDE, to reason about and verify contract behavior at a high level of abstraction, and to generate Solidity code from verified models.
• ContractLarva is a tool that enables extending contracts
  (a) to detect violations at runtime and
  (b) to offer monetary reparations in response to a violation.

References

[1] Atzei, N., Bartoletti, M., Cimoli, T.: A survey of attacks on Ethereum smart contracts (SoK). In: Proceedings of the 6th International Conference on Principles of Security and Trust (POST). pp. 164–186. Springer (April 2017)

[2] Parizi, R.M., Dehghantanha, A., Choo, K.K.R., Singh, A.: Empirical vulnerability analysis of automated smart contracts security testing on blockchains. In: 28th Annual International Conference on Computer Science and Software Engineering (CASCON) (2018)