Closed howlbot-integration[bot] closed 3 months ago
This poses a security risk in case of malicious owner, since disallowedTokens can be withdrawn by owner
koolexcrypto marked the issue as duplicate of #90
koolexcrypto marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-05-loop/blob/40167e469edde09969643b6808c57e25d1b9c203/src/PrelaunchPoints.sol#L364
Vulnerability details
Impact
PrelaunchPoints::allowToken
function is protected byonlyAuthorized
modifier and once the owner decides to allow/whitelist a certain token, the owner will call this function. If in future some changes are introduced that might break our protocol and the owner decides to disallow a certain token, there is no provision in the codebase to disallow that token. Furthermore, there is no proper mechanism in place for the tokenomics when a certain token is disallowed.The chances are really high because certain tokens have upgradable implementations for example
weETH
implementsUUPS proxy
andezETH
implementsUpgradeable Beacon Proxy
Source
Proof of Concept
Owner will not be able to disallow a previously allowed token and if any breaking change is introduced in any one of these tokens then it will badly affect this protocol. It might break the protocol or results into some sort of vulnerability using which the protocol could be compromised or exploited.
Tools Used
Manual review
Recommended Mitigation Steps
PrelaunchPoints::allowToken
should be converted toPrelaunchPoints::toggleAllowToken
or a new function should be created to disallow certain token. Along with this functionality there must be a proper mechanism in place to handle the tokenomics if a token is disallowed.Assessed type
Other