Fjord Token Staking

Summary

1. Depracated SafeMath use

2. Unsafe use of modifiers

3. Insufficient _fjordPoints address check

Vulnerability Details

Deprecated use of SafeMath

Issue: The FjordAuction contract uses the SafeMath library, which is deprecated in Solidity versions 0.8.0 and above. Solidity 0.8.0 introduced built-in overflow and underflow checks, making the use of SafeMath unnecessary.

Impact: Using deprecated libraries can lead to maintenance challenges and potential security risks if the library is no longer supported or updated.

Recommendation: Remove the SafeMath library and rely on Solidity's built-in overflow and underflow checks. This will simplify the code and reduce dependencies.

By making this change, the contract will be more aligned with current best practices and Solidity's built-in features.

Unsafe use of modifiers

Issue: The use of modifiers in the FjordStaking and FjordPoints contracts disrupts the Checks-Effects-Interactions (CEI) pattern. Specifically, the updatePendingPoints, checkEpochRollover, and redeemPendingReward modifiers are used to update the state, which can lead to potential vulnerabilities.

Affected modifiers:

• checkEpochRollover in FjordStaking

• updatePendingPoints in FjordPoints

• redeemPendingReward in FjordPoints

Details:

1. checkEpochRollover:

   • This modifier is used in the FjordStaking contract and updates the state by rolling over the epoch. This disrupts the CEI pattern as it performs state changes before the main function logic is executed.

2. updatePendingPoints:

   • This modifier is used in the FjordPoints contract and updates the pending points for a user. This state change should be handled within the function body rather than in the modifier to adhere to the CEI pattern.

3. redeemPendingReward:

   • This modifier is used in the FjordPoints contract and redeems pending rewards for a user. Similar to the other modifiers, this state change should be moved to the function body to maintain the CEI pattern.

**Impact: **The disruption of the CEI pattern can lead to several issues, including:

1. State Inconsistencies: Modifiers that update the state can cause unexpected side effects, making the contract's behavior harder to predict and audit. This can lead to bugs and vulnerabilities that are difficult to detect and fix.

2. Maintenance Challenges: Using modifiers for state updates complicates the contract's logic, making it harder to maintain and understand. This increases the risk of introducing new bugs during future updates.

Recommendation: Modifiers should be used solely for checking conditions and not for updating the state. The state-changing logic should be moved to the function body to adhere to the CEI pattern, which helps in preventing reentrancy attacks and other potential vulnerabilities.

Insufficient _fjordPoints address check

Issue: The FjordAuctionFactory, FjordAuction, and FjordStaking contracts do not sufficiently validate the _fjordPoints address provided during their initialization. This vulnerability allows a malicious contract that matches the FjordAuctioninterface to be used as the _fjordPoints argument, potentially leading to unauthorized actions and security breaches.

Affected Contracts

• FjordAuctionFactory

• FjordAuction

• FjordStaking

Details: The _fjordPoints address is accepted without validation in the constructors of the affected contracts. This allows any contract that implements the IFjordPoints interface to be passed as the _fjordPoints argument. A malicious actor could deploy a contract that mimics the IFjordPoints interface but contains harmful logic, leading to potential exploits.

Impact:

• Manipulating staking and unstaking operations.

• Interfering with auction processes.

• Misleading the distribution of points and rewards.

• Misleading events emit.

Recommendation:

1. Address Validation: Implement a validation mechanism to ensure that the _fjordPoints address is a legitimate and trusted contract. This can be done by checking the contract's bytecode or by maintaining a whitelist of trusted addresses.

2. Ownership Check: Ensure that the _fjordPoints contract is owned by a trusted entity. This can be verified by calling an owner function on the _fjordPoints contract and comparing it to a known trusted address.