Summary

A low to medium severity vulnerability has been identified in the FjordStaking contract's addAuthorizedSablierSender function. The function lacks a zero address check for its input parameter, potentially allowing the zero address to be added as an authorized Sablier sender. This inconsistency with the contract's constructor could lead to unexpected behavior and potential security risks.

Vulnerability Details

The vulnerability arises from the inconsistency between the constructor and the addAuthorizedSablierSender function in handling zero addresses:

1. In the constructor, there's a check to prevent adding the zero address as an authorized Sablier sender:

1. However, in the addAuthorizedSablierSender function, this check is absent:

This inconsistency allows the zero address to be added as an authorized Sablier sender after the contract deployment, which was explicitly prevented during the contract initialization.

Impact

The impact of this vulnerability includes:

1. Inconsistent Contract State: The contract could end up in an inconsistent state where the zero address is an authorized Sablier sender, contradicting the initial design intention.

2. Potential Security Risks: If other parts of the contract or external systems rely on the assumption that authorized Sablier senders are never the zero address, it could lead to unexpected behavior or security vulnerabilities.

3. Difficulty in Removing Authorization: Since there's no way to remove an address from the authorized list (except through a contract upgrade), adding the zero address by mistake would be irreversible.

4. Increased Attack Surface: An attacker who gains owner privileges could potentially exploit this to disrupt the contract's operations by adding the zero address as an authorized sender.

While the impact is mitigated by the onlyOwner modifier, which restricts the function to be called only by the contract owner, it still represents a design flaw that could lead to unexpected issues.

Tools Used

Manual

Recommendations

To address this vulnerability and maintain consistency with the constructor's behavior, we recommend adding a zero address check in the addAuthorizedSablierSender function. Here's the suggested modification:

This change ensures that:

1. The zero address cannot be added as an authorized Sablier sender.

2. The function's behavior is consistent with the constructor's logic.

3. It provides a clear error message if someone attempts to add the zero address.