Closed code423n4 closed 2 years ago
Duplicate of #168
Duplicate of #168
Note that this is not an exact duplicate IMO as they both reference the same idea in two different functions. That said, I don't think this is a very strong issue given that the external calls seemingly don't care about the share amount received. I believe the protocol moreso intends for the deposit to simply succeed or not, which the current implementation does check.
Given this, I'll downgrade to QA/informational for this warden and not mark it as a duplicate. Generally, the warden's recommendation is not needed at all.
Grouping this with the warden’s QA report #165
Lines of code
https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Swivel/Swivel.sol#L706-L729
Vulnerability details
Impact
Deposit isn't check for minimum share token received (In case of slippage).
Proof of Concept
https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Swivel/Swivel.sol#L706-L729
It only check that fund is deposited successfully but doesn't check that the received share token is enough or not. If one of this protocol can be sandwiched, the fund will be lost to the MEV bot.
Tools Used
Manual review
Recommended Mitigation Steps
Add share token address and minimum share received to the input and perform check at the end to require different in balance to be greater than minimum share.