Fjord Token Staking

Summary:

The FjordStaking contract is vulnerable to inflated reward calculations due to its reliance on the ERC20 token balance to determine available rewards. If tokens are sent directly to the contract without using the designated staking or reward functions, the contract's balance can be artificially increased. This can lead to incorrect reward distributions, potentially draining the contract's legitimate reward reserves and disrupting the intended reward mechanism.

Vulnerability Details:

The FjordStaking contract relies on the balance of the fjordToken to calculate pending rewards during epoch rollovers. If ERC20 tokens are sent directly to the contract address without using the designated stake or addReward functions, the contract's balance can be artificially inflated. This can lead to incorrect reward calculations and distribution, potentially draining the contract's legitimate reward reserves.

Scenario
Setup: The FjordStaking contract is deployed and initialized with the fjordToken as the staking token.

Direct Token Transfer: An attacker or user sends a significant amount of fjordToken directly to the contract address, bypassing the stake or addReward functions.

Inflated Balance: The contract's balance is now artificially inflated due to the direct transfer.

Epoch Rollover: During the next epoch rollover, the _checkEpochRollover function calculates pendingRewards based on the inflated balance.

Incorrect Reward Distribution: The contract distributes rewards based on the inflated balance, leading to excessive rewards being given out.

Resource Depletion: Over time, this could deplete the contract's legitimate reward reserves, resulting in a shortfall when actual rewards need to be distributed to users who have staked properly.

Impact:

Inflated Rewards: The contract may calculate and distribute more rewards than intended due to an inflated token balance.

Resource Drain: Legitimate reward reserves could be depleted, leading to a shortfall when actual rewards need to be distributed to users.

Tools Used:

Manual review

Recommendations:

Implement internal tracking of staked and reward tokens to ensure only explicitly staked or rewarded tokens are considered in calculations.
Avoid relying solely on balanceOf for determining available rewards; instead, maintain an internal ledger.