The core protocol functions, including closeOffer
, relistOffer
, abortBidTaker
, and abortAskOffer
, are vulnerable to reentrancy attacks. This vulnerability arises from not following the check-effects-interaction pattern, which could lead to significant financial losses.
The closeOffer
, relistOffer
, abortBidTaker
, and abortAskOffer
functions do not adhere to the check-effects-interaction pattern, as illustrated below:
The relistOffer
function is susceptible to reentrancy attacks due to the order in which state changes and external calls are made. Here’s a breakdown of how reentrancy can be exploited in this function:
** External Call Before State Update**: The function calls tokenManager.tillIn
to transfer a refund token from the user to the capital pool before updating the offer's status to Virgin
. This is a critical point because an external call (to the tillIn
function) is made before changing the state of offerInfo.offerStatus
.
Potential Attack Vector: If an attacker can control the msg.sender
and has a malicious fallback function in the contract being called, they could re-enter the relistOffer
function before the offerStatus
is updated. This means they can potentially call relistOffer
again while the offer status is still in a state that allows for further execution.
State Manipulation: Since the function allows for the offerStatus
to be manipulated before the status is actually set to Virgin
, an attacker could exploit this by calling the function multiple times, leading to unintended behavior such as multiple refunds or unauthorized state changes.
https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/PreMarkets.sol#L470-L526
User A calls relistOffer
, and the function checks the conditions, then calculates the depositAmount
.
When tokenManager.tillIn
is called, control is passed to an external contract (the token manager).
If this external contract has a malicious fallback function that calls relistOffer
again, the attacker can effectively call the function recursively.
The function's state hasn't been updated yet, so it can still pass the checks, potentially leading to unauthorized access or exploitation of the capital pool.
https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/PreMarkets.sol#L406-L460
https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/PreMarkets.sol#L536-L635
https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/PreMarkets.sol#L645-L697
In the closeOffer
function, refundAmount
is added to the token balance of the user before updating its offerStatus
. An attacker can exploit this by using a malicious contract to re-enter this function, leading to a loss of funds.
In the abortAskOffer
function, the refund amount for the offer authority is updated and added to the offer authority before the offer status is changed. The same attack vector can be utilized to drain protocol funds due to reentrancy.
In the abortBidTaker
function, transferAmount
is added to the token balance of the authority before the stock status is changed. A malicious authority can re-enter this function to steal protocol funds.
Protocol funds will be stolen.
To prevent such reentrancy vulnerabilities, it is essential to follow the check-effects-interactions pattern. This means:
Perform all checks first.
Update all necessary state variables.
Finally, make external calls.
Invalid, all [vague generalities](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#vague-generalities) talking about possible reentrancies 11and afaik, reentrancy is not possible and not proven.
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.