Re-entrancy on `AuraStakingProxy.distributeOther()`

[code423n4]

Lines of code

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

Vulnerability details

CEIP not respected which can open attack vectors for re-entrancy attacks.

Proof of Concept

Note that the external call L219 updates the lastupdateTime, which influences the rewards

File: AuraStakingProxy.sol
199:     /**
200:      * @notice Allow generic token distribution in case a new reward is ever added
201:      */
202:     function distributeOther(IERC20 _token) external {
203:         require(address(_token) != crv && address(_token) != cvxCrv, "not allowed");
204: 
205:         uint256 bal = _token.balanceOf(address(this));
206: 
207:         if (bal > 0) {
208:             uint256 incentiveAmount = bal.mul(callIncentive).div(denominator);
209:             bal = bal.sub(incentiveAmount);
210: 
211:             //send incentives
212:             _token.safeTransfer(msg.sender, incentiveAmount); // @audit-info HIGH CEI not respected which opens the possiblitiy to re-entrancy attacks, consider moving this to the final of the function and add a re-entrancy guard.
213: 
214:             //approve
215:             _token.safeApprove(rewards, 0);
216:             _token.safeApprove(rewards, type(uint256).max);
217: 
218:             //update rewards
219:             IAuraLocker(rewards).notifyRewardAmount(address(_token), bal); //@audit balance update there
220: 
221:             emit RewardsDistributed(address(_token), bal);
222:         }
223:     }
224: }

Mitigations

Consider moving transfer of tokens at the final and add a reentrancy guard.

[dmvt]

The contract in question is a known entity controlled, written, and deployed by the sponsor. As a result we can easily read and evaluate the code for attacks. There is no reentrancy potential here. Invalid.