044.md

Magic Eggshell Stallion

Medium

Admin Arbitrary Overrides of User Rewards

Summary

https://github.com/withtally/staker/blob/90802966475239c3eb8aafc3dbf18edd5a0b6b1b/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L188-L192

https://github.com/withtally/staker/blob/90802966475239c3eb8aafc3dbf18edd5a0b6b1b/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L200-L203 The Tally ARB Staker smart contract exhibits a vulnerability where privileged roles—admin and owner—possess the authority to arbitrarily manipulate user rewards. Specifically, these roles can:

1. Freeze or Inflate Rewards: By using functions like overrideDelegateeScore and setDelegateeScoreLock, an admin can set a delegatee’s score to zero, effectively nullifying rewards for all stakers associated with that delegatee. Conversely, the admin can inflate delegatee scores to disproportionately increase rewards for certain users.

2. Impose Arbitrary Claim Fees: Through setClaimFeeParameters, the admin can set exorbitant fee amounts, potentially confiscating all or a significant portion of users' accrued rewards during claim operations.

3. Enable Malicious Reward Notifiers: Using setRewardNotifier, the admin can authorize malicious notifiers to manipulate the reward distribution schedule, either by extending it indefinitely with negligible increments or by introducing inconsistencies in reward allocations.

Vulnerability Detail

The Tally ARB Staker system allows admins and owners to perform critical operations that can directly influence user rewards. The vulnerability arises from the lack of stringent restrictions and oversight on these privileged functions, enabling potential abuse that can disrupt the reward distribution mechanism.

Affected Functions and Code Snippets

1. Override Delegatee Scores and Locking Mechanism

   • Function: overrideDelegateeScore(address _delegatee, uint256 _newScore)

   function overrideDelegateeScore(address _delegatee, uint256 _newScore) public {
       _checkOwner();
       _updateDelegateeScore(_delegatee, _newScore);
       _setDelegateeScoreLock(_delegatee, true);
   }

   • Function: setDelegateeScoreLock(address _delegatee, bool _isLocked)

   function setDelegateeScoreLock(address _delegatee, bool _isLocked) public {
       _checkOwner();
       _setDelegateeScoreLock(_delegatee, _isLocked);
   }

   Issue: These functions allow the owner to arbitrarily set and lock a delegatee's score. Setting a score to zero effectively nullifies the earning power of all stakers associated with that delegatee, while inflating scores can disproportionately increase rewards.

2. Imposing Arbitrary Claim Fees

   • Function: setClaimFeeParameters(ClaimFeeParameters memory _params)

   function setClaimFeeParameters(ClaimFeeParameters memory _params) external virtual {
       _revertIfNotAdmin();
       _setClaimFeeParameters(_params);
   }

   Issue: This function enables the admin to set the feeAmount to any value, including excessively high amounts. If set higher than typical user rewards, it can effectively confiscate all or most of the rewards during the claim process.

3. Enabling Malicious Reward Notifiers

   • Function: setRewardNotifier(address _rewardNotifier, bool _isEnabled)

   function setRewardNotifier(address _rewardNotifier, bool _isEnabled) external virtual {
       _revertIfNotAdmin();
       isRewardNotifier[_rewardNotifier] = _isEnabled;
       emit RewardNotifierSet(_rewardNotifier, _isEnabled);
   }

   Issue: By enabling a malicious notifier, the admin can manipulate the reward distribution schedule. For instance, they can spam notifyRewardAmount(0) to indefinitely extend the reward period with negligible increments, disrupting fair reward distribution.

Impact

• User Trust Erosion: Such capabilities allow the admin to undermine the fairness and reliability of the staking rewards system, leading to loss of user trust.

• Economic Disruption: Arbitrary adjustments to rewards and fees can destabilize the reward economy, affecting user incentives and overall protocol sustainability.

• Potential for Abuse: If the admin's private keys are compromised or if the admin acts maliciously, users could suffer significant financial losses without recourse.

Tools Used

• Manual Review

• Foundry

---

Recommendations

To mitigate the identified vulnerability and enhance the security posture of the Tally ARB Staker protocol, the following measures are recommended:

1. Implement Multi-Signature Governance for Privileged Actions:
   • Description: Require multiple signatures or a decentralized governance mechanism (e.g., DAO votes) for executing critical admin functions such as overrideDelegateeScore, setClaimFeeParameters, and setRewardNotifier.
   • Benefit: Reduces the risk of unilateral malicious actions by a single admin, ensuring that multiple parties must approve sensitive changes.