Submitted by kirk-baird
AuraLocker.sol#L176-L177
AuraLocker.sol#L802-L814
AuraLocker.sol#L864
There is a potential overflow in the rewards calculations which would lead to updateReward() always reverting.
The impact of this overflow is that all reward tokens will be permanently locked in the contract. Users will be unable to call any of the functions which have the updateReward() modifier, that is:
As a result the contract will need to call shutdown() and the users will only be able to receive their staked tokens via emergencyWithdraw(), which does not transfer the users the reward tokens.
Note that if one reward token overflows this will cause a revert on all reward tokens due to the loop over reward tokens.
This issue will always be present if the staked token is one with a low number of decimal places such as USDC or USDT which have 6 decimal places. This is because the totalSupply will be limited in size by the decimal places of the stakingToken.
The overflow may occur due to the base of values in _rewardPerToken().
The return value of _rewardPerToken() is in terms of
Here (now - lastUpdateTime) has a maximum value of rewardDuration = 6 * 10**5.
Now rewardRate is the _reward.div(rewardsDuration) as seen in _notifyRewardAmount() on line #864. Note that rewardDuration is a constant 604,800.
rewardDuration = 6 * 10**5
Thus, if we have a rewards such as AURA or WETH (or most ERC20 tokens) which have units 10**18 we can transfer 1 WETH to the reward distributor which calls _notifyRewardAmount() and  sets the reward rate to,
rewardRate = 10**18 / (6 * 10**5) ~= 10**12
Finally, if this attack is run either by the first depositor they may lock() a single token which would set totalSupply = 1.
Therefore our equation in terms of units will become,
In since rewardPerTokenStored is a uint96 it has a maximum value of 2**96 ~= 7.9 * 10**28. Hence there will be an overflow in newRewardPerToken.to96(). Since we are unable to add more total supply due to lock() reverting there will be no way to circumvent this revert except to shutdown().
Note this attack is described when we have a low totalSupply. However it is also possible to apply this attack on a larger totalSupply when there are reward tokens which have decimal places larger than 18 or tokens which such as SHIB which have small token value and so many of the tokens can be bought for cheap.
To mitigate this issue it is recommended to increase the size of the rewardPerTokenStored. Since updating this value will require another slot to be used we recommend updating this to either uint256 or to update both rewardRate and rewardPerTokenStored to be uint224.
0xMaharishi (Aura Finance) confirmed, but disagreed with severity and commented:
LSDan (judge) decreased severity to Medium and commented:
0xMaharishi (Aura Finance) resolved:
