The Standard

Summary

If there are 2 point address tokens used as acceptedTokens, users can bypass canRemoveCollateral and remove as much collateral as they want from the vault, making it undercollateralized

Vulnerability Details

removeAsset in SmartVaultV3.sol is used in order for a user to remove mistakenly sent tokens to the vault.

It makes sure that, if a user tries to remove a token which is used as collateral to first go through canRemoveCollateral which is essential to ensure that a vault is not left undercollateralized when removing collateral.

However, if tokens which have 2 addresses are used as acceptedTokens in the vault, a user can easily bypass this check and remove collateral even if he is not supposed to.

1. Call removeAsset with the "non-accepted"(secondary address) address of the accepted token(primary address).

Then:

ITokenManager.Token memory token = getTokenManager().getTokenIfExists(_tokenAddr); will not return a valid token, because the _tokenAddr is not in the accepted ones.

Which means that we will skip if (token.addr == _tokenAddr) require(canRemoveCollateral(token, _amount), UNDER_COLL);, bypassing the canRemoveCollateral.

Then because of how 2-point address tokens work, IERC20(_tokenAddr).safeTransfer(_to, _amount); we will still remove the desired amount from the accepted token which is used as collateral.

Impact

User can get back collateral even when he is not supposed to.

Tools Used

Manual Audit

Recommendations

I can't think of any robust method to prevent this, maybe at the end of the function check if the balances of all acceptedTokens are still the same?