Real Neon Robin - Denial of Service and Gas Inefficiency in buyVotes() Function

[sherlock-admin3]

Real Neon Robin

High

Denial of Service and Gas Inefficiency in buyVotes() Function

Summary

The buyVotes() function in the ReputationMarket contract contains a while loop that adjusts the number of votes to be purchased (currentVotesToBuy) based on the user-provided maxVotesToBuy and the available msg.value. While this dynamic calculation ensures fairness, it introduces significant vulnerabilities when maxVotesToBuy is unreasonably high (given the premium configuration has a max buy/sell votes of 13,300,000) compared to what msg.value can afford.

Root Cause

The root cause of this vulnerability lies in the unconstrained while loop within the buyVotes() function. The loop continues until totalCostIncludingFees isn't higher than the user's msg.value.
If a user provides a very large maxVotesToBuy value that significantly exceeds what their msg.value can purchase, the loop will continue iterating unnecessarily, consuming excessive gas.

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

An attacker or an uninformed user could exploit this vulnerability by:

1. Setup:
   • A user calls buyVotes() with msg.value sufficient for only 2 votes but sets maxVotesToBuy = 1,000,000.
2. Execution:
   • The loop iterates times, consuming excessive gas and possibly exhausting the block gas limit.
3. Result:
   • Transaction fails due to out-of-gas error, or the user incurs unreasonably high gas fees.
   • Other users might experience delayed transactions as blocks reach their gas capacity.

Impact

1. User Gas Costs:
   • The user initiating the transaction faces excessive gas consumption, particularly for large values of maxVotesToBuy.
2. Denial of Service (DoS):
   • If the loop iterates excessively, it may cause the transaction to run out of gas, reverting the transaction. This effectively results in a DoS for the user attempting to buy votes.
3. System-Wide Gas Limitations:
   • Transactions with high gas costs can affect the network block limits, potentially delaying other transactions within the same block.
4. User-Driven Exploit:
   • Even though the vulnerability stems from user-provided inputs, its presence reflects a lack of protective measures in the protocol.

All outcomes can result in a poor user experience, potential financial losses for users, and reduced contract functionality.

PoC

No response

Mitigation

To mitigate this, you can add a check to ensure that the difference between totalCostIncludingFees and msg.value is within a reasonable range before entering the loop. This way, you can prevent the loop from running excessively and consuming too much gas.