What is a reentrancy?

There are plenty of vulnerabilities that a professional blockchain developer keeps in mind and takes into account when developing a smart contract. Ignorance of their patterns and logic can, and often does cost major losses to the projects, and it is not just about monetary losses. One such vulnerability is reentrancy.

In this article, we will dive into the topic of reentrancy, including its definition and mechanics, highlight a few notable real-world cases, spot the main causes of the vulnerability and line out potential ways to mitigate them.

What is it?

Reentrancy in is a concept in which a function can be interrupted and then resumed while its actual execution. With this kind of behavior, the function can be called once again before the first execution is complete. To continue the thought, it is possible to repeat this action (re-enter) over and over again, cyclically.

Reentrancy in terms of smart contract security is a contract vulnerability exploitation that allows an attacker to loop a function execution within its own self.

To be more detailed, reentrancy occurs when a contract function calls a function of another smart contract or library, which in its turn calls the original contract. In this loop, the contract continues to be called and executed until it runs out of gas, some constraint is triggered, or the loop breaks due to an error.

For a more concrete example, imagine a smart contract for a payment gateway. The contract has a withdraw() function that transfers tokens to a specified address and reduces the user's balance.

To enter the attack, an attacker could create his own smart contract that mimics the original gateway. When this contract is invoked, the withdraw() function of the original smart contract is called, which would send the funds to the attacker's address.

But that's just the start of the cycle. Before the first withdraw() function execution completes, the malicious smart contract would call the function again, and continue to do so cyclically many times, transferring funds to the attacker’s wallet.

Real-life examples

Reentrancy is a vuln that unfortunately causes significant losses to blockchain projects quite often.

Among the most iconic examples is the infamous hack of The DAO in 2016. Approximately $60 mil. in ETH was withdrawn using reentrancy. It was this hack that led to the landmark Ethereum fork, which was done to “undo” the attack and recover assets.

BSC-based BurgerSwap protocol hack in 2021, when an attacker exploited a reentrancy using a fake token. The losses amounted to about $7.2 mil. in tokens.

Another example also in 2021 is the SIREN protocol whose AMM-pools were exploited using a reentrancy attack, the damage was around $3.5 mil. in tokens.

Vulnerability specifics

Code that does not apply best practices, tests and code reviews always remains in a potential high-risk zone. However, this vuln is located at the logical level of the contract. Therefore, it is not always easy to trace with basic checks and tests. To put it simply, a contract can be vulnerable to reentrancy even if it is written “bug-free”. Detecting reentrancy is the task of finding a breach in the logic layer.

The main causes

There are many technical code flaws that may lead to reentrancy. Among the common ones are:

• Inefficient input validation: Lack of input validation for consistency increases the risk of reentrancy.
• Insecure function calls. Calling external functions and contracts without checks might lead to exploitation.
• Insecure libraries. Using unsafe, unchecked libraries can increase the risks.
• Unsecured withdrawals. Contracts with unchecked withdrawals are potentially vulnerable to reentrancy.
• Lack of gas optimization. If a contract's gas consumption is not optimized, this increases the potential risk of exploitation
• Inadequate gas limits. If a function has a severely exceeded gas limit, there is a technical opportunity for a hack to occur.
• Lack of locking mechanics. In the absence of locking mechanisms, multiple calls / contract state changes become possible, increasing the risk of reentrancy.
• Lack of tests and code reviews. Lack of quality code reviews and evaluations can lead to many bugs and vulns, including reentrancy.
• Use of non-standard contracts. The use of non-standard, custom, and non-audited contracts may increase the risk of vulnerabilities, including reentrancy.

What are the consequences of the attack?

Reentrancy, like most attacks, can cause several consequences simultaneously, among them:

• Loss of funds and assets. The most obvious one is that the attack results in the loss of user and project assets.
• Product disruption. Due to the attack, the smart contract behaves erratically, which can lead to the disruption of an entire system.
• Reputation damage. Project hack can undermine the reputation of the project and its team or services among users and investors.
• Trust loss. Along with reputational loss, reentrancy can lead to a deterioration in the perception of the entire industry by new adopters.

Mitigating the risks

There are a number of principles that can be used to avoid reentrancy. Among them:

1. Implement proper input validation. Validate all input data to prevent malicious operations.
2. Use safe function calls. Use proper checks and when calling external functions.
3. Secure withdrawals. Pay attention to securing and protecting your withdrawal functions against exploitation.
4. Use locking mechanisms. Lock contract funds using a lockout period or flag to prevent re-withdrawals.
5. Review & audit contracts. Conduct external audits regularly to identify and address vulns before they can be exploited.
6. Use secure contract standards. Use secure standards, such as the ERC-20 token standard, that have built-in sec measures.

Concluding remarks

The blockchain field is full of bright ideas and exciting opportunities, but to achieve the goals and perform best results, courage should go alongside intelligence and awareness of threats. Reentrancy is a logic-level vulnerability that occurs at the intersection of lack of basic good practices and insufficient understanding of contract logic. However, paying attention to code quality, thorough understanding of how the contract operates, what is more important, how it should operate, regular testing, code reviews and high-quality security audits will help prevent many threats including reentrancy.