As blockchain-based programs, programming vulnerabilities within smart contracts are a serious concern. Three types of vulnerabilities within smart contracts are general programming vulnerabilities, blockchain-specific vulnerabilities and platform-specific vulnerabilities.
General programming vulnerabilities
The potential for general programming vulnerabilities exist within smart contracts because they are programs and potentially contain some vulnerabilities as a result. Two examples of general programming vulnerabilities within smart contracts are:
Arithmetic vulnerabilities: Smart contracts commonly perform integer comparisons (for balance checks before performing transfers). Many smart contract platforms used signed and unsigned variables and different length integers, creating the potential for integer overflow and underflow vulnerabilities to enable an attacker to bypass these checks. Right-to-left control characters: Many smart contract platforms have websites that enable users to audit the smart contract code with the intention of building trust in the code. However, these platforms also support right-to-left control characters (for use in handling languages like Arabic that are written right to left), making it possible for the displayed version of the contract to be misleading.
Blockchain-specific vulnerabilities
Smart contracts are programs that run on top of a blockchain, which is a very different operating environment from the computers that many programs are written for. This creates several potential vulnerabilities that are unique to smart contracts:
Access control vulnerabilities: Some smart contracts are designed to provide certain functionality only to the smart contract owner or other privileged users. These lists of privileged users are often set by calling a special function within the contract. However, some contracts fault to set this function to only be callable a single time, granting control to the last person to call the function (instead of the first as was intended). Bad randomness: Many smart contracts need access to a secure source of pseudorandom numbers. However, many of the potential methods of creating this (using a seeded pseudorandom number generator, extracting randomness from features of the distributed ledger and so on) are publicly visible and accessible. This makes it easy for other smart contracts to predict the “random” number and exploit the vulnerable contract. Denial-of-Service attacks: Smart contract code is run by transactions calling that code. If these transactions are unable to be added to the distributed ledger (due to the volume of transactions exceeding the blockchain’s capacity, a block creator refusing to add them to blocks, blocks not being created and so on), then the smart contract cannot be run. Frontrunning: Frontrunning vulnerabilities exist when it is possible for an attacker to observe some action and then take an action that will be processed before the original action. In blockchain, smart contract code is run by transactions and transactions are publicly broadcast to the network and stored in a pool of unused transactions before being added to the ledger by being included within a block. Since transactions are prioritized based upon their transaction fees, an attacker could observe a particular transaction (perhaps calling a smart contract with the solution to a contest or making a trade on an exchange) and create their own competing transaction with a higher fee, making it probable that the attacker’s transaction will be processed before the original transaction. Timestamp dependence: Some smart contracts rely on timestamps to take certain actions (like a contest that begins at midnight on a given day). This is problematic since smart contracts rely upon block timestamps for their view of the current time, and many blockchains allow very flexible timestamps (a later block can even be timestamped earlier than the previous block). This enables a malicious block creator to cheat at a smart contract-based contest by creating a block containing their entry and timestamped to a time after the contest starts well before anyone else has an opportunity to play.
Platform-specific vulnerabilities
Different blockchains implement the smart contract model differently. This creates vulnerabilities specific to a particular platform, such as these Ethereum-specific smart contract vulnerabilities:
Denial-of-Service attacks: The Ethereum platform is vulnerable to DoS attacks taking advantage of gas restrictions on transactions. Every operation within an Ethereum smart contract costs gas and if gas runs out, the execution state is rolled back as if the transaction was never executed. If a smart contract can be put in a state where it requires more gas than a transaction can carry (via loops, recursion and so on), then it is completely unrunnable. Reentrancy: When an Ethereum smart contract is sent Ether, it is permitted to run a fallback function, which can take some action. If this fallback function calls the original smart contract against, it may catch it in an invalid state if the original smart contract has not updated its state (such as the balance within a user’s account). This vulnerability enabled the Ethereum DAO hack. Short addresses: Ethereum right-pads function arguments that are too short. This means that a function that does not perform argument length checking and is designed to check if an operation is valid before calling another function to perform the operation may be validating different argument inputs than the called function uses to perform the operation. Unchecked return values: Different low-level Ethereum functions handle errors in different ways, such as rolling up the execution state versus returning false (which allows execution to continue). Assuming that an error will cause execution to fail and failing to check low-level return values could enable a smart contract to continue to run while in an invalid state.
Securing smart contracts
Smart contracts are programs that are written on the blockchain and often encode valuable functionality (such as processing cryptocurrency or valuable data). These contracts need to be carefully designed to be secure against attack, but the newness of the blockchain ecosystem and these platforms makes this difficult.
Sources
Integer Overflow/Underflow and Floating Point Imprecision, Jolly Fish (Medium) Bitcoin Timestamp Security, Crypto Words Understanding The DAO Attack, Coindesk
