Liquid Staking

Summary

The splitRewards() function in the LSTRewardsSplitter.sol contract is vulnerable to abuse due to the absence of access control. The function can be called by any user, and when the rewards amount is very small, the calculation of amount often results in zero, leading to no actual rewards being distributed to fee.receiver. Malicious users can repeatedly call this function, consuming gas but without transferring any rewards to legitimate recipients. This leads to a denial-of-service-like condition for actual reward distribution.

Vulnerability Details

• No Access Control: The splitRewards() function can be called by anyone because there are no restrictions, such as onlyOwner or other access control mechanisms.

• Zero Reward Distributions: When the _rewardsAmount is very small, the calculation of amount = (_rewardsAmount * fee.basisPoints) / 10000 can frequently result in amount == 0. In such cases:

  • The safeTransfer() and burn() functions are called with amount == 0, meaning no actual tokens are transferred or burned.

  • This allows a malicious user to continuously call splitRewards() without any effective reward distribution, creating unnecessary gas consumption and preventing meaningful transfers.

• Exploitation by Malicious Users: A malicious user can repeatedly call splitRewards() with small increments in rewards, causing the reward calculations to result in zero and wasting gas. This can effectively block the contract from properly distributing rewards to legitimate receivers, leading to potential financial losses due to denial-of-service (DoS) conditions.

Impact

• Gas Drain: Repeated calls to splitRewards() by a malicious user can result in significant gas consumption without actual rewards being transferred. This drains resources and gas but provides no benefit to legitimate participants.

• Denial of Rewards: Since amount often resolves to zero when _rewardsAmount is small, no rewards are transferred to fee.receiver. This means legitimate participants expecting rewards may not receive them as the malicious user continues to exploit the function.

• DoS Condition: By frequently calling splitRewards(), malicious users can effectively prevent legitimate reward distribution, creating a denial-of-service condition where actual users cannot claim their rightful rewards.

Tools Used

• Manual code review and analysis of the access control and reward calculation logic.

• Understanding of smart contract execution costs, reentrancy risks, and reward distribution patterns.

Recommendations

Restrict splitRewards() to onlyOwner:

• Add access control to the splitRewards() function by restricting it to the contract owner or a specific role (e.g., using OpenZeppelin's Ownable contract). This prevents arbitrary users from calling the function and abusing the gas consumption.

Example implementation: