Dria

Summary: getRoundPhase is a public view function that relies on block.timestamp (a constantly changing value), an attacker could monitor the function to get a near-optimal timing for other transactions, especially if those transactions are only favorable in certain phases, especially near phase or round transitions.

Vulnerability Detail:

The purchase function can potentially be front-run due to its dependency on the current phase (specifically, the purchase phase). Key Variables in purchase Vulnerable to Front-Running

1. Phase Dependency:

   • The purchase function only executes successfully during the Buy phase, as enforced by _checkRoundPhase(Phase.Buy).

   • Attackers could monitor for phase changes and submit transactions precisely when the contract enters the Buy phase, potentially blocking or manipulating the intended timing of other purchase calls.

   • The attacker monitors calls to getRoundPhase to detect when the contract enters the Buy phase.

   • When the Buy phase begins, the attacker can submit a transaction with a higher gas price than others to ensure it is mined first.

   • Once the attacker’s transaction is submitted first, they effectively block others

2. Attack Example with Numerical Timing

   1. Phase Transition Timing

      • At block.timestamp = 1979, we are in the Sell phase (2nd round).

      • At block.timestamp = 1980, the phase transitions to Buy.

      • At block.timestamp = 2030, it transitions to Withdraw.

   2. Attack via Optimized Calls

      • An attacker monitors the block.timestamp and calls getRoundPhase at block.timestamp = 1979.

        • Result: It returns (1, Phase.Sell, 1), indicating 1 second until the Buy phase.

        • The attacker can now prepare a getRoundPhase transaction and broadcast it to the network, but intentionally set the gas price to ensure it’s mined at block.timestamp = 1980.

        • When block.timestamp = 1980 arrives, getRoundPhase will report that we’re in the Buy phase.

        • Another user, unaware of the attack, also calls purchase at block.timestamp = 1981, expecting it to be in the Buy phase. However, the attacker’s optimized transaction was already executed right at the start of the Buy phase.

        • This creates a scenario where the other user’s purchase might fail or be front-run by the attacker.

Impact: Timing Exploitation: An attacker can call getRoundPhase and time their transactions, impacting other users who rely on the same phase-sensitive operations.

Tools Used

Recommendations: Cooldown Mechanisms: Introducing a brief cooldown period or grace interval between phases could prevent phase-sensitive operations from being exploited within a single block.