The contract is vulnerable to a potential gas limit DoS attack due to the unbounded iteration over the VOTERS
array. This issue arises in several key functions: selectPresident()
, _selectPresidentRecursive()
, _isInArray()
.
These functions rely on looping through the VOTERS
array, which is a storage variable. If the number of voters is extremely large, the gas consumption for these loops increases significantly. This can result in transactions exceeding the block gas limit, causing the transaction to fail. As a result, the system would effectively become unusable, preventing the selection of a new president.
Although the contest documentation mentions that the set of voters is initialized during contract construction, there is no specified limit for the maximum number of voters. Given that a real-world presidential election could involve millions of voters, this lack of a cap could lead very well to a possible DoS attack.
The vulnerability poses a significant denial of service risk. If the number of voters becomes large enough, transactions for selecting the new president will fail due to exceeding the block gas limit. This could result in the contract being unable to execute core functionality such as selecting a new president, freezing the election process indefinitely.
Manual review, vscode
Here are a few strategies that could optimize the handling of large voter datasets:
Instead of iterating over the storage array directly, use mappings, which provide more efficient lookups than arrays in Solidity.
Read candidate votes into memory, perform the required operations, and only write back the results to storage once computations are complete.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.