Closed c4-bot-7 closed 5 months ago
Attention !, _maxSharePrice needs to be turned to true so you could do liquidations that will create share balances for the liquidator, with the actual code you can not do that because of an rounding bug that have been reported in other finding
This finding is invalid as it tries to proof it self by suggesting the initial code submitted needs to be modified in order for this finding to work. But the code does not need to be modified, previous findings are out of scope and all fixes for rounding were already applied before code got submitted for the competition, hence no change should be made. There is also no rounding bug in the submitted code base as it rounds as expected against the user, otherwise other attacks can becomes possible again.
If you disagree then we can discuss first the "finding" you are referring to that you mark as "rounding bug" that needs to be addressed first making this finding then dependent on another "finding" valid outcome or being yet another manipulation to convince everyone there is an "issue"
Worth giving a double check just in case, that said, the sponsor dispute is legitimate
GalloDaSballo marked the issue as primary issue
GalloDaSballo marked the issue as insufficient quality report
We are talking about liquidators on either eth main ( can use eden or flashbots) and on arbitrum there is no mempool. Therofr dismissed
Attention !, _maxSharePrice needs to be turned to true so you could do liquidations that will create share balances for the liquidator, with the actual code you can not do that because of an rounding bug that have been reported in other finding
This finding is invalid as it tries to proof it self by suggesting the initial code submitted needs to be modified in order for this finding to work. But the code does not need to be modified, previous findings are out of scope and all fixes for rounding were already applied before code got submitted for the competition, hence no change should be made. There is also no rounding bug in the submitted code base as it rounds as expected against the user, otherwise other attacks can becomes possible again.
If you disagree then we can discuss first the "finding" you are referring to that you mark as "rounding bug" that needs to be addressed first making this finding then dependent on another "finding" valid outcome or being yet another manipulation to convince everyone there is an "issue"
The reasoning above is valid. Warden has not demonstrated why enabling maxSharePrice
is likely, meaning it is invalid speculation of code.
We are talking about liquidators on either eth main ( can use eden or flashbots) and on arbitrum there is no mempool. Therofr dismissed
The reasoning above is not valid for Eth. The fact liquidators may go to private mempools is not valid assumption for reduction of severity.
trust1995 marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L1250 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/MainHelper.sol#L614
Vulnerability details
In the event of a rapid market downturn ( e.g USDC de-pegging/UST Luna crash etc... ) liquidations could be blocked by a sophisticated user that have access to MEV infrastructure. Function liquidatePartiallyFromTokens is not doing any checks to see if the caller of the function (msg.sender) is the owner of the nft position or it is approved to operate with it. If you are going in the case where there will not be enough tokens to pay the liquidator a position will be created for him. Currently the number of positions at this moment is limited to 8 (hardcoded value), but the protocol have stated they will support more then 8. Cominbing all this factors, the sophisticated user could frontrun the transactions that want to liquidate him and do liquidations in their name to create more positions until they have 8 positions in userTokenData and when the liquidations transaction that will liquidate the sophisticated user will take place it will revert with error TooManyTokens() as a new positions can not be added for that liquidator.
Impact
Liquidatons could be blocked for a period of time, in case of high market downturn that time is not necessarily to be very long as the protocol does not allow liquidations with a collateralPercentage bigger then 100% which can result in high accumulating of bad debt rapidly.
Proof of Concept
To run the following test use the following command. (Attention !, _maxSharePrice needs to be turned to true so you could do liquidations that will create share balances for the liquidator, with the actual code you can not do that because of an rounding bug that have been reported in other finding)
The output of the test
We can observed that the last liquidation transaction have been reverted with the error TooManyTokens() so the test have passed.
Tools Used
Manual Reivew
Recommended Mitigation Steps
Assessed type
DoS