Chilly Bamboo Cormorant - Potential Risks from Missing Validation and Input Checks in GammaRewarder Contract

[sherlock-admin3]

Chilly Bamboo Cormorant

Low/Info

Potential Risks from Missing Validation and Input Checks in GammaRewarder Contract

Summary

Missing input validation on multiple occassions in the GammaRewarder contract.

Root Cause

Multiple instances where input validation is missing which makes the contract vulnerable to incorrect parameters or unauthorized inputs. The specific instances of missing validation are the following:

1. constructor(address brevisProof, address _protocolFeeRecipient): No check for zero address on _protocolFeeRecipient.
2. setBlocksPerEpoch(uint64 _blocksPerEpoch): Missing validation to ensure _blocksPerEpoch > 0.
3. toggleTokenWhitelist(address token): Missing check to ensure token is non-zero.
4. setProtocolFeeRecipient(address _feeRecipient): Lacks zero address validation for _feeRecipient.

Internal pre-conditions

1. constructor: The _protocolFeeRecipient parameter is expected to be a non-zero address, which is essential for protocol fee transfers.
2. setBlocksPerEpoch: The _blocksPerEpoch should be a positive value greater than zero.
3. toggleTokenWhitelist: The token should be a valid, non-zero address.
4. setProtocolFeeRecipient: The _feeRecipient must be a valid non-zero address to receive protocol fees.

External pre-conditions

1. Malicious Intent: Attackers attempt to exploit any open or zero address in contract functions.
2. Contract Owner Negligence: If the contract owner inadvertently sets a zero address in functions, it can cause critical failures or security risks in the contract.

Attack Path

No response

Impact

Inappropriate settings for _protocolFeeRecipient and _blocksPerEpoch could lead to unexpected contract behavior and disruption in reward distributions.

Unauthorized claims due to missing userAddress validation could lead to fund losses, affecting the intended beneficiaries of reward distributions.

Non-zero address validation on token and _feeRecipient is essential for maintaining a valid contract state, as incorrect parameters can introduce inconsistencies that may affect the entire reward mechanism.

PoC

No response

Mitigation

Add input validation which will ensure that the input parameter != 0 or != address(0):

// Mitigation for constructor validation
constructor(address brevisProof, address _protocolFeeRecipient) BrevisApp(IBrevisProof(brevisProof)) Ownable(msg.sender) {
++ require(_protocolFeeRecipient != address(0), "Invalid protocol fee recipient address.");
   protocolFeeRecipient = _protocolFeeRecipient;
}

// Mitigation for blocks per epoch validation in setBlocksPerEpoch
function setBlocksPerEpoch(uint64 _blocksPerEpoch) external onlyOwner {
++  require(_blocksPerEpoch > 0, "Blocks per epoch must be greater than zero.");
    blocksPerEpoch = _blocksPerEpoch;
    emit BlocksPerEpochUpdated(_blocksPerEpoch);
}

// Mitigation for non-zero token validation in toggleTokenWhitelist
function toggleTokenWhitelist(address token) external onlyOwner {
++  require(token != address(0), "Token address cannot be zero.");
    uint256 toggleStatus = 1 - isWhitelistedRewardToken[token];
    isWhitelistedRewardToken[token] = toggleStatus;
    emit TokenRewardWhitelistToggled(token, toggleStatus);
}

// Mitigation for fee recipient validation in setProtocolFeeRecipient
function setProtocolFeeRecipient(address _feeRecipient) external onlyOwner {
++  require(_feeRecipient != address(0), "Invalid fee recipient address.");
    protocolFeeRecipient = _feeRecipient;
    emit ProtocolFeeRecipientUpdated(_feeRecipient);
}