Closed c4-bot-1 closed 4 months ago
Picodes marked the issue as unsatisfactory: Insufficient proof
Hello, if you test the poc you would see that it is just as I said. Please kindly review this issue as it is not "unsatisfactory" and not eligible but supposed to be eligible. Thank you for your assistance
What about this line https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/CollateralTracker.sol#L418 ?
Sorry what does this mean? Users can make deposits of up to type(uint104).max so it is just as I said. In periods of high deposits and low withdrawals with a very active pool when s_poolAssets overflow this would break core protocol invariant as users lose deposited assets.
@UnknownBlackman my bad, please disregard my previous comment. I still believe this issue is out of scope considering the readme:
"Very large quantities of tokens are not supported. It should be assumed that for any given pool, the cumulative amount of tokens that enter the system (associated with that pool, through adding liquidity, collection, etc.) will not exceed 2^127 - 1. Note that this is only a per-pool assumption, so if it is broken on one pool it should not affect the operation of any other pools, only the pool in question."
@Picodes Thank you for taking your time to review this issue. I appreciate. However, I still believe this issue to be valid.
Thank you and I hope you reconsider
@UnknownBlackman I respectfully disagree and this reasoning doesn't hold. There are countless ERC20s that are not supported by Panoptic out there (fee on transfer, rebasing, scams, etc) and you can't make a check for every one of them so it makes sense to have assumptions. In addition to this I can't accept a report that the team explicitly flagged as being out of scope.
Lines of code
https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/CollateralTracker.sol#L436
Vulnerability details
Details
Users can make deposits of Collateral tokens into the pool through the
CollateralTracker.deposit
and receive shares for their deposits. These shares can later be redeemed for their initial deposits. When deposits are made, thes_poolAssets
is incremented with the assets deposited while the totalSupply is incremented with the shares minted to the user.The reverse happens when the shares are redeemed or withdrawn. s_poolAssets is incremented in an
unchecked
keyword allowing overflow. Sinces_poolAssets
is a uint128, and maxDeposit is uint104.max, it is highly possible to get s_poolAssets to uint128.max. Only 16 million max deposits are required to get this value. In a very active pool, getting to this value is a relatively small feat.Impact
It is expected that users should be able to always redeem their shares for the same amount of asset initially deposited no matter the conditions in the pool. What happens when
s_poolAssets
gets to uint128.max, and a user deposits enough to cause an overflow (This can be as little as 100 assets deposit), that user would never get their assets back and their assets would be lost forever. Infact, all other users of the pool would also get seriously impacted as well. This breaks core protocol functionality. However, I believe the impact is a medium due to the edge case thats_poolAssets
would eventually get to max value especially during periods of high deposits and low redeem or withdrawal. But still, this is still very likely to happen.Proof of Concept
Insert the following into
CollateralTracker.t.sol
I have mocked the s_poolAssets to be close to type(uint128).max and also totalSupply inCollateralTracker
has been modified close to type(uint128).max to manually balance the accounting.Tools Used
Manual Review
Recommended Mitigation Steps
CollateralTracker.previewDeposit
This should effectively mitigate this issue.
Assessed type
Under/Overflow