Flow

Summary:

There were multiple instances in the codebase where address state variables are assigned values without sufficient validation to check for address(0). The lack of these checks can lead to significant risks, as address(0) is conventionally used in Solidity to represent an uninitialized or null state, which could have critical implications for contract functionality and security.

Vulnerability Details:

The issue was identified in the following locations:

1) src/abstracts/Adminable.sol - Line 36

2) src/abstracts/SablierFlowBase.sol - Line 60

3) src/abstracts/SablierFlowBase.sol - Line 61

4) src/abstracts/SablierFlowBase.sol - Line 248

5)src/abstracts/SablierFlowBase.sol - Line 271

Impact:

Inability to Perform Privileged Actions:

• Admin Functions: Many contracts include administrative functions that require a valid address to operate correctly. If the admin variable is inadvertently set to address(0), the contract will not have a functional administrator. This means that essential tasks such as pausing the contract, upgrading components, or executing privileged operations will be rendered impossible. In a crisis, when urgent actions are needed, the contract will be effectively immobilized.

Loss of Control and Governance:

• Contract Governance: If a governance contract or a multi-signature wallet is assigned an address(0), the ability to manage or govern the contract is compromised. This can lead to scenarios where decisions that affect the entire ecosystem cannot be made, potentially leaving users vulnerable to issues that could have been managed with proper oversight.

Malicious Exploits:

• Privilege Escalation: If attackers can manipulate contract interactions (e.g., by providing a malicious input to a function), they may exploit the lack of validation for address assignments to set critical variables to address(0). This scenario creates a pathway for privilege escalation, where the attacker can lock out legitimate administrators and gain control of the contract’s functionality.

• Reentrancy Attacks: In contracts where functions rely on valid addresses for state changes (like transfers), setting an address to address(0) could inadvertently open up the contract to reentrancy vulnerabilities. An attacker could exploit this during an operation, as the contract’s state could be in flux, leading to unintended and potentially exploitable states.

Contract Failures and Loss of Funds:

• Transaction Failures: Assigning address(0) to critical variables can lead to functions that revert when they attempt to interact with those addresses. This situation can cause transactions to fail, resulting in a poor user experience and frustration. Users may lose gas fees without successfully completing their intended operations.

• Loss of Assets: If a function that transfers tokens or assets relies on an address that is set to address(0), those assets could become permanently inaccessible. For example, attempting to send tokens to address(0) typically results in a loss of those tokens, as they would not be retrievable from an uninitialized address.

Data Corruption:

• Mapping Issues: If mappings or arrays that depend on address assignments are not properly validated, setting an address to address(0) can lead to incorrect data states. For instance, if a mapping from token addresses to balances is corrupted by assigning address(0) as a key, the balance could reflect inaccuracies, leading to issues in token transfers and user balances.

Tools Used: Slither and Aderyn.

Recommendations:

Implement Validation Checks:

• Require Statements: Before assigning any value to address state variables, incorporate require statements to check that the address is not address(0). This ensures that only valid addresses are assigned, preventing uninitialized or null values from being stored.

Centralize Address Assignments:

• Utilize Setter Functions: Create dedicated setter functions for address assignments to ensure that all assignments go through the same validation logic. This encapsulation allows for consistent checks and reduces the chances of missing validations in multiple locations.

Add Events for Address Changes:

• Emit Events on Assignments: Emit events when critical addresses are assigned or updated. This provides transparency and enables tracking of changes, which can aid in audits and debugging.

Use Custom Errors for Clarity:

• Define Custom Error Messages: Instead of using standard revert messages, consider defining custom error types to provide more context about the error when address validations fail. This can help developers and users quickly understand the nature of the failure.