Target
Bug Description
One of the core invariants of the CCollateralCapERC20 token is that totalCollateralTokens < collateralCap. It is meant to ensure collateral may be sold with sufficient liquidity and ensures the safety of the liquidation mechanism.
Every time account balance is accessed, initializeAccountCollateralTokens() is called to make sure the collateral balance is initialized. This function matches the collateral amount to the user's balance and does not check the invariant totalCollateralTokens < collateralCap. total is incremented by: totalCollateralTokens = add_(totalCollateralTokens, accountTokens[account]);
In any other location is code where the user collateral is increased it is done via increaseUserCollateralInternal function which enforces the cap.
This means once cap has been reached, the protocol is subject to collaterization out-of-bounds of up to the total uninitialized assets, i.e. users who did not participate in the protocol up to this point. Furthermore, after the cap is passed, during transfers and liquidations, collateralTokens will be moved from origin to destination and not be absorbed by the protocol. This means the cap will likely not self-correct and only continue to spiral larger.
Impact
Protocol is subject to liquidation insolvency risks which it explicitly is meant to protect against.
Risk Breakdown
Difficulty to Exploit: Medium
Weakness: Logic error
Recommendation
In initializeAccountCollateralTokens set user's collateral through increaseUserCollateralInternal() to enforce the cap.
Consider a fair collateral distribution scheme so that users can get their existing amounts in collateral tokens. For example, up to some defined block.number, collateral is only increased to pre-existing amount, so users cannot drain the collateral rights from others.
References
https://coinmarketcap.com/alexandria/glossary/collateral-cap - By Puff from I.B.
Iron Bank claims that they already placed a conservative value in the max collateral cap, so it is not a big deal if it is exceeded due to this scenario. In my opinion, it is nontransparent to the users which don't have the complete picture of how many collateral tokens are yet to be issued this way. IB chose the lazy approach and are not interested in making things more complicated for themselves.
Comentarios