The attacker can seize all whitelists

[c4-bot-2]

Lines of code

https://github.com/code-423n4/2024-06-vultisig/blob/cb72b1e9053c02a58d874ff376359a83dc3f0742/hardhat-vultisig/contracts/Whitelist.sol#L65-L74 https://github.com/code-423n4/2024-06-vultisig/blob/cb72b1e9053c02a58d874ff376359a83dc3f0742/hardhat-vultisig/contracts/Whitelist.sol#L232-L235

Vulnerability details

Impact

The contract opens a whitelist for purchasing tokens. By simply transferring ETH to the contract, one can join the whitelist. An attacker can use many addresses to conduct preemptive transactions, thereby filling up the 1,000-slot whitelist, and forcing the protocol to open additional whitelists. In addition, attackers may become dominant participants ("whales") and disrupt the protocol's ecosystem.

Proof of Concept

The VultisigWhitelisted contract implements the whitelist function. When _isSelfWhitelistDisabled is false (the default situation), users can join the whitelist by simply transferring ETH to the contract, and the transferred ETH is returned. This incurs no cost. An attacker can create a large number of accounts to seize whitelist spots, thereby disrupting the normal operation of the protocol. This also circumvents the per-user purchase limits.

    receive() external payable {
        if (_isSelfWhitelistDisabled) {
            revert SelfWhitelistDisabled();
        }
        if (_isBlacklisted[_msgSender()]) {
            revert Blacklisted();
        }
        _addWhitelistedAddress(_msgSender());
        payable(_msgSender()).transfer(msg.value);
    }

Tools Used

manual

Recommended Mitigation Steps

It is recommended that the protocol manually select whitelist users or require a higher cost for joining the whitelist.

Assessed type

Access Control

[Scorpiondeng]

Hi @alex-ppg ,thank you for your judgement Please take a look at this finding, even though #42 fixes this issue still exists and has a similar impact as #42. Because front-running is entirely possible, this makes the whitelist mechanism ineffective. So I think a high risk rating is appropriate.

[alex-ppg]

Hey @Scorpiondeng, thank you for the PJQA contribution. I will preface all validation repository finding responses by stating that they are not evaluated by judges directly and are only evaluated by the validators if they are deemed unsatisfactory.

The attack described is unreasonable, and the intention of the whitelist's first-come-first-serve approach is to facilitate a "race" of who's the first to enter it. As such, this submission will remain invalid.

This paragraph is included in all of my responses and confirms that no further feedback is expected in this submission as PJQA has concluded. You are free to refute any of my statements factually, however, I strongly implore you to do this with actual code references and examples.