Reward can be locked in pool when initialize after startTime

[code423n4]

Lines of code

https://github.com/code-423n4/2022-05-aura/blob/4989a2077546a5394e3650bf3c224669a0f7e690/contracts/AuraBalRewardPool.sol#L205

Vulnerability details

Impact

• After startTime anyone can call initialiseRewards() to init AuraBalRewardPool.
• The attacker can used it to front run when someone transfer reward in. These tokens is locked forever in the contract because there is no way to emergency withdraw or set rewardRate again.

Proof of concept

• https://github.com/code-423n4/2022-05-aura/blob/4989a2077546a5394e3650bf3c224669a0f7e690/contracts/AuraBalRewardPool.sol#L205
• Attacker transfer duration amount of rewardToken to the pool, just enough for the attack.
• Because of some reason (forget), after startTime, reward manager is going to init the reward pool. First he/she must transfer some amount of rewardToken into the pool.
• Attacker see the pending TX and try to front run by calling initialiseRewards(). Now because it’s pass the startTime, attacker can call it and set rewardRate to very low value (= 1 in this case).
• The amount of rewardToken that reward manager transfer into will be locked there because rewardRate is set and noone can call ​​initialiseRewards() again.

Tools Used

Manual Review

Recommended Mitigation Steps

You can allow reward manager to update rewardRate. Of course, we have to updateReward first before recalculate the rate or add function to withdraw the left over.

[0xMaharishi]

Technically true, but this is not how this works. The reward tokens are transferred far ahead of time

[dmvt]

The code is working as expected. If the rewardManager fails to perform their duty before the start time, the contract can be easily redeployed. Invalid.