The Frequent Occurrence of Reentrancy Issues—painful but solvable

In recent Blockchain Audit Contests, reentrancy issues have been frequently identified. This vulnerability, once considered “old,” continues to recur in many emerging projects despite extensive industry education and awareness campaigns. This article uses the Star project from a specific contest as a case study to analyze the mechanisms, impacts, and root causes of reentrancy issues.

Background: The History and Current State of Reentrancy Issues

Reentrancy attacks are one of the classic vulnerabilities in smart contracts. They first occurred in 2016 during the infamous DAO incident, which resulted in losses exceeding $60 million within the Ethereum ecosystem. Today, despite significant improvements in development tools and auditing processes, reentrancy issues are still repeatedly discovered across various projects. This is because such attacks exploit flaws in the execution order between state updates and external calls, a logical vulnerability that is often overlooked in complex contract interactions, with consequences that can be catastrophic.

Project Overview: The Star Project

Star is a decentralized blockchain project aimed at building a social network aggregation platform and an omni-chain naming service. Its core goal is to assist users in managing identities and data across multiple blockchains while integrating and displaying their social activities on different platforms. As a rapidly growing user product, Star has attracted significant funding and held an audit contest prior to its launch, inviting multiple auditors to review the project’s security to ensure its reliability and safety.

During the audit contest, auditors identified several potential risks, including a typical reentrancy attack issue. This problem was assessed as a “high-risk vulnerability,” which the project team promptly addressed. However, this incident highlighted deficiencies in security considerations during the development process.

Case Study

In one of Star’s smart contracts, the following withdrawal logic exists:

function withdraw(uint256 amount) public {  

  require(balances[msg.sender] >= amount, "Insufficient balance");  

  (bool success, ) = msg.sender.call{value: amount}("");  

  require(success, "Transfer failed");

  balances[msg.sender] -= amount; 

} 

Problem Analysis:

1. Order of State Updates: The balances variable is updated only after transferring funds to the user, creating a time window for attackers to repeatedly call the contract’s function or conduct other malicious actions.
2. Risk of External Calls: If msg.sender is an external smart contract, it can trigger a receive callback to re-enter the withdraw function (i.e., reentrancy), draining all funds from the smart contract.

Attack Steps:

1. The attacker deploys a malicious contract that automatically triggers its receive() or fallback() callback function upon receiving funds; this callback includes the contract’s withdraw() method.
2. The attacker calls the withdraw function.
3. The contract sends amount of funds to the user via call().
4. The malicious contract’s callback function calls the withdraw() method again; since balances[msg.sender] has not yet been set to zero, the attacker can withdraw funds multiple times.
5. The attacker repeats step 4 until the contract’s balance is depleted.

Reentrancy issues are not limited to the Star project; they have also been widely exploited in various other security incidents:

1. The DAO Incident: The DAO (Decentralized Autonomous Organization) was a smart contract platform built on Ethereum that allowed users to invest and participate in decision-making. In 2016, it suffered a reentrancy attack where attackers exploited a vulnerability through recursive calls to steal over 50 million ETH (approximately $150 million). Attackers created a sub-contract that repeatedly called the DAO contract before updating balances, allowing them to withdraw funds multiple times despite built-in self-protection mechanisms. The Ethereum community executed a hard fork to fix this vulnerability, resulting in two separate chains: Ethereum (ETH) and Ethereum Classic (ETC).
2. The decentralized platform Incident: Cream Finance is a decentralized lending platform that supports mid- to long-tail assets and has expanded across multiple blockchains (e.g., Ethereum, BSC, Polygon). On August 30, 2021, it experienced a flash loan attack where attackers acquired 420 million AMP tokens, 1308 ETH, and some USDC stablecoins worth over $18 million by initially taking out a flash loan of 500 ETH as collateral for borrowing 19 million AMP tokens. During this process, they exploited a reentrancy vulnerability to borrow an additional 355 ETH and liquidate their loans multiple times.
3. Multi-Chain Bridge Fund Losses: Penpie is a decentralized financial protocol similar to other DeFi platforms that allows users to participate in liquidity mining and earn rewards. On September 3, 2024, Penpie suffered a reentrancy attack where attackers exploited vulnerabilities within the contract to pose as legitimate users during liquidity reward distribution phases, leading to asset losses totaling $27.34 million.

Summary of Root Causes of Issues

1. Objective Reasons: Reentrancy issues are prone to occur due to:
   1. Language Mechanism: Solidity allows external contracts to trigger callback functions, providing technical grounds for reentrancy attacks.
   2. Logical Complexity: The complexity involved in state updates and fund flows within smart contracts makes it easy to overlook security checks.
2. Subjective Reasons: Weak security awareness contributes:
   1. Developer Shortcomings: Many smart contract developers lack experience in secure development practices and have insufficient understanding of reentrancy issues.
   2. Neglect by Project Teams: Project teams often prioritize rapid feature deployment over thorough security audits or believe basic testing suffices for all issues.

Conclusion

The frequent occurrence of reentrancy issues reflects weak security aspects in smart contract development. Through this contest case study, it becomes evident that while the essence of vulnerabilities remains unchanged, their exploitation methods may become more covert.To prevent similar issues:

1. Developers should adhere to secure development principles such as checks-effects-interactions patterns.
2. Utilize tools and audits for regular static code analysis and dynamic testing.
3. Enhance security education and training to improve awareness among developers and project teams.

The security of smart contracts is not just a technical issue but also foundational for the sustainable development of the entire Web3 ecosystem. It is hoped that this article provides valuable insights for developers as we collectively advance the safety and stability of Web3 projects.