If a payer calls repayBorrowBehalf() with amount == uint(-1), the call can be frontRun by the borrower with a borrow() call, increasing accountBorrows[borrower].principal, leading to the payer paying more than expected.
That is because here, the amount the payer will pay is set to the borrower's balance (when amount = uint(-1)).
The payer paid more than expected, meaning the borrower essentially stole the additional borrow balance he created with the front run borrow() call.
Because of KYC, this issue is less likely to happen, but it is still profitable, and the malicious user can back run both calls with a redeem() call in fToken to retrieve all their underlying before being added to a sanctionsList.
Note that it is contingent on repayer approving fToken a high enough amount for the attack to happen, but because the amount to repay() is unknown at the time of function call (because of interests not accrued yet), it is likely the payer will approve a higher value anyway.
Tools Used
Manual Review
Recommended Mitigation Steps
Consider adding some sort of "slippage" in repayBorrowBehalf() , ie the maximum amount the payer agrees to repay for the borrower.
Lines of code
https://github.com/code-423n4/2023-01-ondo/blob/main/contracts/lending/tokens/cToken/CTokenModified.sol#L751
Vulnerability details
Impact
If a payer calls
repayBorrowBehalf()
withamount == uint(-1)
, the call can be frontRun by theborrower
with aborrow()
call, increasingaccountBorrows[borrower].principal
, leading to the payer paying more than expected.That is because here, the amount the payer will pay is set to the borrower's balance (when amount = uint(-1)).
The payer paid more than expected, meaning the borrower essentially stole the additional borrow balance he created with the front run
borrow()
call.Because of KYC, this issue is less likely to happen, but it is still profitable, and the malicious user can back run both calls with a
redeem()
call infToken
to retrieve all their underlying before being added to asanctionsList
.Note that it is contingent on repayer approving
fToken
a high enough amount for the attack to happen, but because the amount to repay() is unknown at the time of function call (because of interests not accrued yet), it is likely the payer will approve a higher value anyway.Tools Used
Manual Review
Recommended Mitigation Steps
Consider adding some sort of "slippage" in
repayBorrowBehalf()
, ie the maximum amount the payer agrees to repay for the borrower.