INCOMPATIBILITY WITH REBASING/DEFLATIONARY/INFLATIONARY TOKENS CAN RESULT IN UNDERCOLLATERALIZED LOAN
The current version of the codebase does not handle special cases of tokens, e.g. deflationary, rebasing, whose balance changes during transfers or over time. The necessary checks include at least verifying the amount of tokens transferred to contracts before and after the actual transfer to infer any fees/interest. Some function transfers tokens from msg.sender(ie an external user) to the contract but it does not check the return value, which can in some cases result in undercollateralized loans.
the token is a fee-on-transfer ERC20 token, and the InceptionVaultCore contract only receives 995 tokens.
_addCollateralToVault() is called with _amount equal to 1000: the collateral balance of Alice's vault will be equal to 1000, despite the fact the InceptionVaultCore only received 995 tokens.
borrow() calculates the maximum amount of PAR that can be borrowed using a user's collateral balance: Alice can call this function to borrow an amount of PAR that will result in an undercollateralized loan
Tools Used
Manual Analysis
Recommended Mitigation Steps
Consider checking the actual balances transferred (balance after-before) or clearly documenting that you do not support deflationary / rebasing / etc tokens.
Lines of code
https://github.com/code-423n4/2022-04-mimo/blob/b18670f44d595483df2c0f76d1c57a7bfbfbc083/core/contracts/inception/InceptionVaultsCore.sol#L123 https://github.com/code-423n4/2022-04-mimo/blob/b18670f44d595483df2c0f76d1c57a7bfbfbc083/core/contracts/inception/InceptionVaultsCore.sol#L280 https://github.com/code-423n4/2022-04-mimo/blob/b18670f44d595483df2c0f76d1c57a7bfbfbc083/core/contracts/inception/InceptionVaultsCore.sol#L306 https://github.com/code-423n4/2022-04-mimo/blob/b18670f44d595483df2c0f76d1c57a7bfbfbc083/core/contracts/inception/InceptionVaultsDataProvider.sol#L66
Vulnerability details
INCOMPATIBILITY WITH REBASING/DEFLATIONARY/INFLATIONARY TOKENS CAN RESULT IN UNDERCOLLATERALIZED LOAN
The current version of the codebase does not handle special cases of tokens, e.g. deflationary, rebasing, whose balance changes during transfers or over time. The necessary checks include at least verifying the amount of tokens transferred to contracts before and after the actual transfer to infer any fees/interest. Some function transfers tokens from msg.sender(ie an external user) to the contract but it does not check the return value, which can in some cases result in undercollateralized loans.
Impact
Medium
Proof Of Concept
InceptionVaultsCore.sol line 121
deposit()
, withamount
= 1000 tokensInceptionVaultCore
contract only receives 995 tokens._addCollateralToVault()
is called with_amount
equal to 1000: the collateral balance of Alice's vault will be equal to 1000, despite the fact the InceptionVaultCore only received 995 tokens.borrow()
calculates the maximum amount of PAR that can be borrowed using a user's collateral balance: Alice can call this function to borrow an amount of PAR that will result in an undercollateralized loanTools Used
Manual Analysis
Recommended Mitigation Steps
Consider checking the actual balances transferred (balance after-before) or clearly documenting that you do not support deflationary / rebasing / etc tokens.