Closed c4-bot-10 closed 5 months ago
On corePaybackFeeManager()
there syncPool()
modifier is called in which _syncPoolBeforeCodeExecution()
is called and in this function the function _checkReentrancy()
is triggered.
Beside that there are not token sent to the user in corePaybackFeeManager()
. At the end after _updateUserBadDebt()
the incentive token are sent to the user as you can see in the function.
GalloDaSballo marked the issue as insufficient quality report
trust1995 marked the issue as unsatisfactory: Insufficient proof
Lines of code
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/FeeManager/FeeManager.sol#L730-L814
Vulnerability details
Impact
An attacker could potentially drain the contract's funds by repeatedly calling the function before the
badDebtPosition
mapping is updated. Here's how the reentrancy attack could work:paybackBadDebtForToken
from within itsfallback
function.paybackBadDebtForToken
with their malicious contract as the caller.paybackBadDebtForToken
function, the contract transfers thereceivingAmount
tokens to the attacker's malicious contract before updating thebadDebtPosition
mapping.paybackBadDebtForToken
again.badDebtPosition
mapping hasn't been updated yet, the attacker can repeatedly receive thereceivingAmount
tokens. This attack can continue until the contract's funds are depleted or the gas limit is reached. The severity of this vulnerability is considered high because it could lead to a complete loss of funds for the contract. An attacker could potentially drain all the tokens held by the contract, resulting in a significant financialProof of Concept
The
paybackBadDebtForToken
function is also vulnerable to reentrancy attacks. An attacker could potentially call this function recursively before thebadDebtPosition
mapping is updated, leading to multiple paybacks of the same bad debt. True or false, explain in details how this works, what is the impact ? show relevant code sections and explain proof of concept and vulnerability details. Use code to explain how it can be mitigated. ThepaybackBadDebtForToken
function is indeed vulnerable to a reentrancy attack. Here's a breakdown of the vulnerability and how it can be exploited: 1.The function updates thebadDebtPosition
mapping after transferring thereceivingAmount
and thepaybackAmount
tokens. This means that an attacker's malicious contract can re-enter the function before thebadDebtPosition
mapping is updated.paybackBadDebtForToken
and receive thereceivingAmount
token.Before the
badDebtPosition
mapping is updated, the attacker's contract would recursively callpaybackBadDebtForToken
again, exploiting the fact that thebadDebtPosition
mapping has not been updated yet. 4.This recursive call would allow the attacker to receive additionalreceivingAmount
tokens before thebadDebtPosition
mapping is updated, effectively draining the contract's tokens. Here's the relevant code section that illustrates the vulnerability:function paybackBadDebtForToken( uint256 _nftId, address _paybackToken, address _receivingToken, uint256 _shares ) external returns ( uint256 paybackAmount, uint256 receivingAmount ) { updatePositionCurrentBadDebt( _nftId );
}
Tools Used
Manual
Recommended Mitigation Steps
Follow the "Checks-Effects-Interactions" pattern and update the
badDebtPosition
mapping before transferring any tokens. Here's how you can modify thepaybackBadDebtForToken
function:In this modified version, the
badDebtPosition
mapping is updated before transferring any tokens, preventing the reentrancy attack. Additionally, a check is added to ensure that the badDebtPosition is not zero before proceeding with the payback process. By following the "Checks-Effects-Interactions" pattern and updating the critical state variables before any external interactions, you can effectively mitigate the reentrancy vulnerability in thepaybackBadDebtForToken
function.Assessed type
Other