Before the New Year, let’s finally talk about the security features of Ethereum.
Bugs that are impossible to fix
Once a contract is publicly available on the blockchain, it cannot be modified. Accordingly, there is no chance to correct any bugs in the contract. If you want to be able to fix bugs, you need to leave some code in the contract to modify or terminate the contract. But the backdoor option is controversial because ethereum’s vision is that smart contracts, once deployed, are supposed to be immutable in their Settings.
Because the bug cannot be modified formally, it may lead to some very serious attack events without remedy. DAO attacks are the only exception. Ethereum uses a hard fork to solve this problem. But this approach did not sit well with the entire community because it violated the maxim that “code is law.”
Call stack size limit
Each time a contract calls another contract, a frame is added to the stack. The maximum number is 1024. When this limit is reached, the next call raises an exception. If the attacker calls the victim contract’s function by filling its stack one frame short, then any calls in the victim function’s execution will fail. If the victim function does not properly handle successful execution, unexpected results can result. We’ll illustrate this with an example later in this article.
To address this issue, in an Ethereum upgrade, it was specified that each call to a contract function via Call or Delegatecall can allocate a maximum of 63/64 remaining gas to the called function. Each block in Ethereum can contain a maximum of about 4.7 million gas. That is, if the caller initially invested a quantity of GAS, after 10 recursive calls, the innermost function is at most (63/64)^10* A of gas. As a result, the call depth cannot exceed 1024. In the case of subsequent attacks, it is assumed that this fix is not already available.
Time constraints
A large number of applications use time constraints to determine when certain behaviors are allowed. An ERC 20 contract, for example, allows users to use Ether to buy a token at some point.
During the execution of a smart contract, the current time is taken from the block timestamp of a given exchange in the block. So, all transactions in a block are executed using the same timestamp. This ensures that the results of the smart contract will be the same for each miner.
But this setting could also lead to some attacks, because miners have some autonomy in choosing timestamps, which could open the door for some attacks.
Attack by GovernMental contract
GovernMental is a “Ponzi scheme” type of contract. Technically, it’s not cheating, because the rules of a Ponzi scheme are written out in the contract. In this contract, each person participates in the Ponzi scheme by transferring a sum of money into the contract. The contract records the addresses of the participants and the amount of money each participant transfers through two arrays. If no one joins for 12 hours after the last person joins, the last person gets all the proceeds. (Doesn’t this look a bit like the famous Fomo3D, which, it’s worth noting, came out later than this paper.)
Here’s a simplified version of a GovernMental contract
In this contract, participants can invest ether and join the game via the invest() function. The contract maintains a variable called jackpot that says how much ether the winner will take if no one joins later. The new participant must put more than half of ether into the jackpot, and half of ether into the jackpot will be added. If there is no new participant for a minute, the last person gets the ether in the jackpot, and the contract owner takes the rest of the money (leaving 1 ether as the next round of startup money). Note that there is no check to see if the transfer through the send() function was successful at the last penny.
This simplified version of the contract has several points to attack.
Attack a
This attack comes from the contract owner itself and is intended to prevent the original game winner from getting paid. The contract owner attacks with exception handling of the send() function and call stack size limits.
The attack is done by making so many recursive calls up front that when resetInvestment() is executed, the call stack reaches its maximum size and can no longer execute the send() function for game winners and contract owners. Neither the contract owner nor the game winner gets paid. The money remains in the contract, but the code that resets the contract status is then executed as usual. With just one more round of normal play, the contract owner can pocket the money that would have gone to the winner of the previous round.
Attacks on two
This line of attack comes from the miners. Miners can make the person they want to win the contract game by refusing to package someone else into a deal with a GovernMental contract. What’s more, the miners who attack the block can decide the order in which they want to trade when they package the block, influencing who is lastInvestor after that block.
As mentioned earlier, the amount of ether that each new participant needs to put in cannot be less than half the amount of ether in the jackpot in the contract. The number of jackpots a person sees when they initiate a trade may not be the same as the number of jackpots a person sees when their trade is executed. This leads to the possibility that the person may initiate a trade thinking that the amount of ether they put in is the right amount. However, when executed, the jackpot value changes and becomes an invalid transaction. This is the problem of unpredictable states mentioned in the previous article.
In addition, miners have the right to determine the block’s timestamp. When the contract is executed, to determine whether resetInvestment can be executed is to read the block time stamp decided by the miner. By affecting block timestamps, you can also affect the outcome of the game.
conclusion
Through these sessions on reference [1] we have seen some weaknesses in the design of ethereum Solidity contracts. Although these weaknesses are not called vulnerabilities, contracts with security issues can be written without adequate understanding and consideration of these points when they are written.
References: [1] Atzei, Nicola, Massimo Bartoletti, and Tiziana Cimoli. “A survey of attacks on ethereum smart contracts (sok).” Principles of Security and Trust. Springer, Berlin, Heidelberg, 2017. 164-186.
Conflux is committed to building the next generation of high-performance DAPP public chain platform
Welcome to follow our wechat official account: Conflux Chinese Community (Conflux-chain)
Add wechat group administrator Confluxgroup replied “Add group” to join the Conflux official communication group
