The refund
function in the provided code is vulnerable to reentrancy attacks.
The vulnerability arises from the order of operations in the refund
function. The function first sends the entranceFee
to msg.sender
using the .sendValue()
function. However, this function can trigger a fallback function in the recipient contract, allowing for reentrant calls. After the value is sent, the playerIndex
is set to address(0)
to mark the player as refunded. This creates a window of opportunity for an attacker to reenter the receive
function before the playerIndex
is set to address(0)
.
The following is a simplified example of how an attacker can exploit the reentrancy vulnerability:
In this proof of concept, the MaliciousContract
is deployed and passed the address of the vulnerable contract. When the AttackRaffle
function is called, it triggers a reentrant call to the refund
function of the vulnerable contract. The receive function in MaliciousContract
then reenters the vulnerable contract's refund
function, allowing the attacker to drain the contract's balance.
Allows the attacker to repeatedly call the refund
function and drain the contract's balance : Steal of funds.
Manual review.
To mitigate this vulnerability, consider implementing the following measures:
Use the "Checks-Effects-Interactions" pattern to ensure that state changes occur before interacting with external contracts.
Alternatively, consider using a reentrancy guard.
reentrancy in refund() function
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.