[M-02] Once a token is allowed using `PrelaunchPoints::allowToken` function, there is no way to disallow

[howlbot-integration[bot]]

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 by onlyAuthorized 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 implements UUPS proxy and ezETH implements Upgradeable 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 to PrelaunchPoints::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

[0xd4n1el]

This poses a security risk in case of malicious owner, since disallowedTokens can be withdrawn by owner

[c4-judge]

koolexcrypto marked the issue as duplicate of #90

[c4-judge]

koolexcrypto marked the issue as unsatisfactory: Invalid