Loss of tokens for the Owner who called the lockOnBehalf function.
Proof of Concept
In the lockOnBehalf function, if a user locks tokens on behalf of another user and mistakenly uses the wrong user address, the tokens will be locked in the contract under the wrong user's account. As a result, the wrong user can unlock these tokens, leading to potential loss of tokens for the intended user.
Scenario:
User A intends to lock tokens on behalf of User B but mistakenly uses User C's address.
User A calls lockOnBehalf with User C's address as the _onBehalfOf parameter, locking tokens for User C instead of User B.
User C, the unintended recipient, can now unlock the tokens that were mistakenly locked for him, leading to a loss of tokens for User B.
Tools Used
Manual Review
Recommended Mitigation Steps
Add 2 step verification for the call in which OnBehalf confirms the transaction.
(Or)
In the ERC20 standard, if User A mistakenly approves tokens for User C instead of User B, User A can later correct this by calling approve with 0 tokens for User C. This revokes the approval, ensuring that User C cannot spend the tokens. However, in the current contract's lockOnBehalf function, there is no similar mechanism to revoke the lock in case of a mistake.
Lines of code
https://github.com/code-423n4/2024-05-munchables/blob/main/src/managers/LockManager.sol#L275
Vulnerability details
Impact
Loss of tokens for the Owner who called the
lockOnBehalffunction.Proof of Concept
In the
lockOnBehalffunction, if a user locks tokens on behalf of another user and mistakenly uses the wrong user address, the tokens will be locked in the contract under the wrong user's account. As a result, the wrong user can unlock these tokens, leading to potential loss of tokens for the intended user.Scenario:
Tools Used
Manual Review
Recommended Mitigation Steps
Add 2 step verification for the call in which OnBehalf confirms the transaction. (Or) In the ERC20 standard, if User A mistakenly approves tokens for User C instead of User B, User A can later correct this by calling approve with 0 tokens for User C. This revokes the approval, ensuring that User C cannot spend the tokens. However, in the current contract's lockOnBehalf function, there is no similar mechanism to revoke the lock in case of a mistake.
Assessed type
DoS