Closed code423n4 closed 1 year ago
0xSorryNotSorry marked the issue as primary issue
outdoteth marked the issue as sponsor disputed
The problem is that the wrapper contract "EthRouter" only supports the native ETH for the base token.
Yes... that is why it is called EthRouter. If a user wants to deposit into an ERC20 pool they need to create an ERC20Router.
Closing per sponsor comment
GalloDaSballo marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-04-caviar/blob/main/src/PrivatePool.sol#L478-L507 https://github.com/code-423n4/2023-04-caviar/blob/main/src/EthRouter.sol#L219-L248
Vulnerability details
Impact
A wrapper contract is suggested for users prior to calling the function "deposit", but the wrapper contract doesn't actually handle ERC20 deposits to the private pools. Therefore users are still enforced to use the not safely deposit function in the pool.
Proof of Concept
The natspec on the deposit function in the private pool clearly states, that a user should only call this function unless he knows what's his doing. And the dev suggest that a wrapper contract is used instead which will check that the current price is within the desired bounds inputted by the user.
The problem is that the wrapper contract "EthRouter" only supports the native ETH for the base token. Therefore users can't actually use the safe wrapper contract which checks the desired bounds as depositing ERC20 tokens to the private pool doesn't work. As a result the only way for users to deposit ERC20 would be to call the not safely deposit function in the private pool.
Tools Used
Manual review
Recommended Mitigation Steps
Consider adding a check ensuring that the current price is between the desired bounds as the wrapper contract doesn't handle deposits with ERC20 tokens.