User can bypass RiskConfig.borrowATokenCap
limit up to 10x times using multicall. Leading to temporary DOS attack
#34
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-238
🤖_11_group
AI based duplicate group recommendation
satisfactory
satisfies C4 submission criteria; eligible for awards
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-06-size/blob/8850e25fb088898e9cf86f9be1c401ad155bea86/src/libraries/CapsLibrary.sol#L19-L44
Vulnerability details
Multicall only validates that the total USDC deposit does not exceed 1M USDC. This limited validation overlooks users’ existing balances, enabling them to deposit multiple times over the limit.
The validation logic checks for excess USDC deposits and repayment of debt. If the debt reduction surpasses the deposit, the transaction does not revert, allowing users to bypass the deposit limit.
Since this validation ignores the current user's deposited balance, users can repeatedly deposit and repay to exceed the cap.
Impact
Proof of Concept
By making self loan with 0% interest to self and 1 hour tenor limit. Fee is tiny with 1h tenor.
Deposit 1M and borrow 1M USDC from self. Users cannot deposit anymore at this point because 1M is maximum limit of total deposit.
However, calling
multicall()
with deposit 1M and repay 1M will work because user reduce credit by the same amount of deposit. Resulting in a total of 2M deposit on smart contract.Repeat this multiple times until you are 10x over limit deposit and preventing anyone else from making deposit.
Foundry test for reproducing.
Tools Used
Recommended Mitigation Steps
None. There is no practical reason to have deposit limit.
Otherwise, this is good application for transient storage with multicall.
Assessed type
DoS
The text was updated successfully, but these errors were encountered: