It was brought to our attention that a hard-to-produce, but important bug exists in the canonical staker contract.
The createIncentive() function does not check that the rewardToken address contains bytecode when invoking transferFrom() via address.call(). This means it's possible to successfully create an incentives program for a reward amount without actually transferring any token over if the rewardToken address has no bytecode.
Potential Attack
- Front-run the deployment of a new token by starting an incentives program with the token address before that token address has bytecode. An incentives program is created without any reward tokens having been transferred.
- Wait for a legitimate incentives program to be created after the token has been deployed.
- The attacker could then drain the reward token amount from the legitimate incentives program, given the malicious incentives program has ended, therefore allowing the incentive creator to collect all unclaimed rewards.
Solution
Check that the rewardToken contract has bytecode before creating an incentive with that token. This will ensure that createIncentive will revert if the full token amount is not transferred to the staker contract.
It was brought to our attention that a hard-to-produce, but important bug exists in the canonical staker contract.
The createIncentive() function does not check that the rewardToken address contains bytecode when invoking
transferFrom()via address.call(). This means it's possible to successfully create an incentives program for a reward amount without actually transferring any token over if the rewardToken address has no bytecode.Potential Attack
Solution
Check that the rewardToken contract has bytecode before creating an incentive with that token. This will ensure that createIncentive will revert if the full token amount is not transferred to the staker contract.