Liquid Staking

Summary

The LSTRewardsSplitter and LSTRewardsSplitterController contracts within the stake.link platform allow the contract owner to manage fee receivers through the addFee and updateFee functions. However, these functions lack validation to prevent setting the fee receiver to the zero address (address(0)). If a fee receiver is inadvertently or maliciously set to the zero address, any attempt to distribute rewards will fail, leading to a Denial of Service (DoS) for the reward distribution mechanism.

Vulnerability Details

Adding a Fee with the Zero Address

Explanation:
The owner calls the addFee function with _receiver set to address(0) and _feeBasisPoints set to 100 (representing 1%). Since there is no validation to prevent the zero address, the fee is successfully added to the fees array.

Attempting to Split Rewards

Explanation:
When splitRewards is invoked, the contract iterates through all configured fees and attempts to transfer the specified fee amount to each receiver. Encountering the zero address as a fee receiver, the safeTransfer function from OpenZeppelin's SafeERC20 library reverts the transaction, causing the entire splitRewards function to fail.

Expected Revert Message

Explanation:
The transaction reverts with the message "ERC20: transfer to the zero address" due to the failed attempt to transfer tokens to an invalid address, effectively halting the reward distribution process.

Impact

• Denial of Service (DoS):
  The inability to distribute rewards disrupts the platform's core functionality, preventing users from receiving their staking rewards.

• Economic Impact:
  Users relying on timely reward distributions may lose trust in the platform, potentially leading to decreased participation and staking activity.

• Operational Disruption:
  The platform requires manual intervention by the owner to rectify the fee receiver address, which can delay reward distributions and affect user satisfaction.

Tools Used

Manual Review

Recommendations

Implement Validation Checks

To prevent setting the fee receiver to the zero address, introduce validation within the addFee and updateFee functions.

Updated addFee Function

Explanation:
A require statement ensures that the _receiver is not the zero address before adding the fee, preventing accidental or malicious misconfiguration.

Updated updateFee Function

Explanation:
The require statement ensures that the _receiver is not the zero address unless the _feeBasisPoints is set to zero, which effectively removes the fee.