Petite Slate Orangutan
High
Potential Front-running and Back-running Vulnerabilities in the BinaryEligibilityOracleEarningPowerCalculator Contract
Front-running could occur when an attacker observes a pending transaction that will affect a delegatee's score and uses this knowledge to submit a transaction with a higher priority to manipulate their earning power before the original transaction is mined.
Back-running may happen if an attacker waits for a transaction that updates delegatee scores and then submits a competing transaction right after it, exploiting the new state of the contract to gain an advantage in earning power calculations.
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L167-L179 Vulnerability: If an attacker is aware of an imminent score update, they may attempt to front-run the update to benefit from a higher earning power, or back-run by reacting to the public state change to manipulate the system.
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L234-L242 An attacker may adjust their strategy based on the new score and eligibility status (especially if scores are updated frequently). Back-running can be done by reacting quickly after a legitimate user’s score is updated and using this knowledge to adjust earning power eligibility.
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L129-L136 Vulnerability: Front-running can occur if an attacker knows when a delegatee’s eligibility is about to change, allowing them to stake and benefit from the delegatee's status before the update.
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L145-L160 Vulnerability: An attacker could back-run a transaction to adjust earning power eligibility just before the update, gaining an advantage by staking right after an eligibility threshold is reached.
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L248-L256 Vulnerability: If the oracle pause state can be exploited, an attacker could prevent legitimate updates from being processed, leading to delayed eligibility changes and possible back-running opportunities.
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L300-L303 Vulnerability: If a delegatee’s score can be locked by an attacker or someone with privileged access, it could be used to front-run or prevent changes to eligibility, especially in cases where the score is supposed to change based on new information.
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L324-L331 Vulnerability: A privileged actor, such as the owner, could change the threshold, leading to manipulations in eligibility, which could allow an attacker to gain full earning power unfairly.
Assumptions Attack Context: A user updates the score of a delegatee via the updateDelegateeScore function, and an attacker seeks to manipulate the earning power calculation by submitting a competing transaction before or after the legitimate update.
Vulnerable Function: The contract relies on the delegatee’s score to determine eligibility for full earning power, making it susceptible to attacks if the delegatee’s score is updated in a predictable manner.
Front-running PoC Initial Setup:
User (victim) wants to update a delegatee's score using the updateDelegateeScore function. Attacker watches for this transaction in the mempool and knows the delegatee’s score is about to be updated. The attacker submits a transaction to manipulate the delegatee’s score before the victim's transaction is mined. Steps for Front-running:
Attacker observes the mempool for transactions that will call updateDelegateeScore. The attacker submits a competing transaction to manipulate the delegatee’s score before the victim’s transaction. Since the contract does not have any nonce-based checks or a commitment phase, the attacker's transaction can be mined first, giving them an advantage.
// Front-run attacker transaction
function attackFrontRunning(address victim, address delegatee, uint256 manipulatedScore) external {
// Assume we can observe the victim's update in the mempool
// Manipulate the delegatee's score before the victim's transaction is mined
binaryEligibilityOracleEarningPowerCalculator.updateDelegateeScore(delegatee, manipulatedScore);
}Outcome: The attacker's score manipulation is processed before the legitimate score update from the victim, potentially leaving the attacker in a better position for earning power calculation. Back-running PoC Initial Setup: The victim successfully updates the delegatee’s score via the updateDelegateeScore function. The attacker waits for the victim’s transaction to be mined and then submits a new transaction to manipulate the delegatee's score right after the legitimate update. Steps for Back-running: The attacker monitors the blockchain for the victim’s transaction and waits for it to be mined. Once the score is updated, the attacker submits a new transaction to modify the score to a new value, affecting the earning power calculation in their favor.
// Back-run attacker transaction
function attackBackRunning(address victim, address delegatee, uint256 manipulatedScore) external {
// Assume we observe the mining of the victim's transaction
// Manipulate the delegatee's score immediately after the victim's transaction is mined
binaryEligibilityOracleEarningPowerCalculator.updateDelegateeScore(delegatee, manipulatedScore);
}Outcome: The attacker's transaction is mined immediately after the legitimate score update, allowing them to exploit the new state of the contract and potentially gain an advantage in the earning power calculation.
Commit-Reveal Scheme Introduce randomness or custom transaction ordering Block Confirmation Delay