Backd Tokenomics contest - csanuragjain's results

Lines of code

https://github.com/code-423n4/2022-05-backd/blob/main/protocol/contracts/RewardHandler.sol#L50

Vulnerability details

Impact

burnFees will fail if none of the pool tokens have underlying token as native ETH token. This is shown below. Since burnFees fails so no fees is deposited in BKDLocker

Proof of Concept

1. Assume RewardHandler.sol has currently amount 5 as address(this).balance (ethBalance) (even attacker can send a small balance to this contract to do this dos attack)
2. None of the pools have underlying as address(0) so no ETH tokens and only ERC20 tokens are present
3. Now feeBurner.burnToTarget is called passing current ETH balance of amount 5 with all pool tokens
4. feeBurner loops through all tokens and swap them to WETH. Since none of the token is ETH so burningEth_ variable is false
5. Now the below require condition fails since burningEth_ is false

require(burningEth_ || msg.value == 0, Error.INVALID_VALUE);

6. This fails the burnFees function.

Recommended Mitigation Steps

ETH should not be sent if none of pool underlying token is ETH. Change it to something like below:

bool ethFound=false;
for (uint256 i; i < pools.length; i = i.uncheckedInc()) {
            ILiquidityPool pool = ILiquidityPool(pools[i]);
            address underlying = pool.getUnderlying();
            if (underlying != address(0)) {
                _approve(underlying, address(feeBurner));
            } else
{
ethFound=true;
}
            tokens[i] = underlying;
        }

if(ethFound){
        feeBurner.burnToTarget{value: ethBalance}(tokens, targetLpToken);
} else {
feeBurner.burnToTarget(tokens, targetLpToken);
}

Lines of code

https://github.com/code-423n4/2022-05-backd/blob/main/protocol/contracts/BkdLocker.sol#L70

Vulnerability details

Impact

If Governor mistakenly adds duplicate reward token then user will get more funds

Proof of Concept

1. Assume rewardToken was X and _replacedRewardTokens was empty
2. Governor calls migrate function and mistakenly again provides newRewardToken as X
3. First X will be removed from _replacedRewardTokens, since it does not exist, nothing happens

_replacedRewardTokens.remove(newRewardToken);

4. Now X is added to _replacedRewardTokens at current block timestamp

 _replacedRewardTokens.set(rewardToken, block.timestamp);

5. Now new rewardToken is also set as X

6. Finally this becomes like below

_replacedRewardTokens=[X]
rewardToken=X

7. This is incorrect since this will give double rewards to user when _userCheckpoint function is called (once by increasing curRewardTokenData.userShares[user] and secondly by increasing prevRewardTokenData.userShares[user], both of which are same tokens)

Recommended Mitigation Steps

Add a check to see that new reward token is not equal to existing reward token

require(newRewardToken!=rewardToken, "Migration not required");

https://github.com/code-423n4/2022-05-backd/blob/main/protocol/contracts/utils/Preparable.sol#L143

Function _setConfig: No need to set deadlines[key] = 0; as this was already done in _executeDeadline function

https://github.com/code-423n4/2022-05-backd/blob/main/protocol/contracts/tokenomics/Minter.sol#L218

Function _mint: Check that amount is not equal to zero

amount!=0

Note: do same for mintNonInflationTokens

https://github.com/code-423n4/2022-05-backd/blob/main/protocol/contracts/tokenomics/LpGauge.sol#L59

Function claimRewards: Since amount is uint type so amount cannot be <0. Change it to

if (amount == 0) return 0; 

Note: Same need to be fixed for other Gauge like AMMGauge

https://github.com/code-423n4/2022-05-backd/blob/main/protocol/contracts/BkdLocker.sol#L214

Function claimFees: If claimable is zero, no need to go further

require(claimable!=0);