Scanning Live Ethereum of Unchecked-Send Error Contracts. Part 2

Original author: <a href="http://hackingdistributed.com/zikai/"> Zikai Alex Wen </a> and <a href="http://hackingdistributed.com/amiller/"> Andrew Miller </ a >

Transfer

Continuation of the article “Scanning Live Ethereum of contracts for the error“ Unchecked-Send ”. Part 1 " .

Almost a year ago (while Ethereum was in its “border” release), the popular lottery contract EtherPot [9] also suffered from the same error. An earlier version of BTCRelay also showed this error [7] . Although a danger was discovered in a previous security audit, an incorrect patch was first applied [8] .

Unchecked-send error detection on live blockhain

How common are these errors? Do you heed warnings? Do best practices apply? We answer these questions empirically by analyzing the block-chain Ethereum data, as well as the repository of the Solidity code repository found on etherscrape.com. To do this, we are developing a simple software analysis tool that checks the block-chain contract and uses heuristics to check whether one of the most effective protection methods is being used. Listing 2 shows the first protection technique, as recommended in the Ethereum documentation, which should check the return value of send and throw an exception. To detect the use of this method, we use a rough approximation: we simply look to see if the return value of send is ignored or not.

Listing 4 illustrates the second protection technique recommended in the UMD manual, which directly checks if the callstack is full by sending a test message. To discover this technique, we again use an approximate approximation: we simply check if a message is being sent in addition to the send command .

If none of these heuristic indicators are present, we conclude that none of the best practice recommendations are followed. We implement these heuristics using a simple pattern mapping with a compiled EVM byte code. For more details on how we do this, see Appendix [12] .

How many contracts are vulnerable?

We start by checking the heuristics in the Etherscrape repository of the Solidity source code. As of March 20, 2016, Etherscrape retransmission contained 361 Solidity contract programs, 56 of which contained the send instruction. Of these contract programs, we assume that most (at least 36 out of 56) do not use any of the protective programming methods.

Even if the contract does not use any of the security technologies, it may or may not have a real vulnerability. We manually checked the Solidity contracts to confirm the presence of the vulnerability. For our purposes, we treat a contract as vulnerable if its state may change, even if the send command does not work (so we will look at the vulnerable code in Listing 5). We confirmed that the vulnerability is present in the vast majority, 32 out of 36 of these contracts.

Similarly, our heuristics do not guarantee the correct application of defensive programming. Take, for example, “WeiFund”, a decentralized open-source crowdfunding DApp. This contract has two functions: refund () and payout () , which trick our heuristics. The following is an excerpt from the refund .

function refund(uint _campaignID, uint contributionID) public {
...
  receiver.send(donation.amountContributed);
  donation.refunded = true;
...
  if(c.config != address(0))
  WeiFundConfig(c.config).refund(_campaignID, donation.contributor, 
  donation.amountContributed);  
}

In this code, the message is sent to WeiFundConfig (c.config) to call the refund method, but only under certain conditions. If c.config is zero, then the contract is indeed vulnerable to a callstack attack. When testing *, none of the Solidity programs that have passed our heuristic test have actually applied the recommended best practice of testing callstack directly. *

Then we turn our attention to contracts drawn up on the live block-chain Ethereum. We looked at a snapshot of March 20, 2016 (time stamp: 1184243). This snapshot contains a total of 13,645 block chains, which appear to be generated by the Solidity compiler, of which only 1,618 (11.8%) included the send command .

Of these, the vast majority do not seem to use any of the defensive programming techniques.

How about the recursive race problem in TheDAO? The most exciting smart contract these days, TheDAO [11] , suffers from a completely separate error, which is that it is not “safe for reuse” [13] . This is another (related, but distinct) kind of insecure programming, which was also expected in previous security checks [6] , but probably still many contracts are unsafe today. Future work was to make a tool that could also detect such an error.

Where did it all go wrong?

We do not expect that programming on smart contracts will be completely simple, at least for now. However, it is surprising that this particular form of error is so common, despite the fact that it was described so long ago during the development of the Ethereum ecosystem.

In a report in 2015 [6], this recommendation was given to the developers of Ethereum: "

At present, the programming examples presented in the documentation are insufficient to disseminate advanced methods for writing safe contracts and solving problems with the gas mechanism. Introductory C ++ textbooks often skip
error checking for readability, which led to numerous security errors. Examples of Ethereum should teach the best habits. Recommendation: provide even more examples of thoroughly programming defensive contracts. "

We only know one official answer to this question, which is to add a warning to the official Solidity documentation mentioned earlier [3], repeated below:" There is some danger when using send : The transfer fails if the call stack depth is 1024 (this can always be caused by the caller), and also fails if the receiver runs out of gas. Therefore, to ensure the safe transmission of the air, always check the return value of send or even better: use a template in which the recipient withdraws money. "

We believe that this remark is not enough to document the problem. It offers only incomplete mitigation and describes only one option of danger, potentially misleading the reader about its degree.

Update: The
inadequacy of the Solidity documentation has also been illustrated in detail by Peter Spring. [sixteen]

In addition, the warning seems to be often ignored. Therefore, we believe that additional preventive measures should be taken.

How can Etherscrape help?

We believe that using static analysis tools, even rough ones, such as those described in this message, can help improve the quality of intelligent contracts. At Etherscrape, we integrate analysis tools like this into our publicly accessible web service, and we add a link to the tool page when it is ready. This will make it easier to view the code of an intelligent contract, highlighting the places where errors may occur. We assume that users of such a smart contract (for example, potential investors in TheDAO or its offers) can easily use tools such as sanity checks before depositing their money. Even non-technical investors can hold developers accountable for explaining how they reacted to the problems noted in the code.

Etherscrape also helps by analyzing the public block chain and controlling the prevalence of this error, which can help in deciding, for example, how much money to allocate for research and development of static analysis tools. In addition, compilers such as solc can integrate such analyzes, providing a warning to the programmer when an error seems probable.

Recommended literature

Tags: