The splitRewards
function in the LSTRewardsSplitter
contract is declared as external and lacks proper access control mechanisms.
This permits any external account to invoke the function, enabling them to trigger the reward splitting process at will.
As a result, the intended reward threshold mechanism can be bypassed, leading to premature and potentially unfair distribution of rewards, and undermining the integrity of the reward logic.
The splitRewards
function is defined without any access control modifiers such as onlyController
or onlyOwner
, making it accessible to anyone:
This lack of restriction allows any user to call splitRewards
, regardless of whether the reward threshold set by the controller
has been met.
The reward threshold is intended to prevent the splitting of rewards until a certain amount of new rewards have accumulated.
By calling splitRewards
directly, an attacker can:
Bypass the reward threshold: Triggering reward distribution before the minimum reward amount is reached.
Manipulate timing of rewards: Continuously call splitReward
to distribute rewards in smaller, inefficient amounts.
Potentially disrupt reward calculations: Frequent splitting might affect the accuracy of reward allocations due to rounding errors or increased gas costs.
Furthermore, while the performUpkeep
function includes a threshold check, it also lacks access control, allowing any user to call it. However, it will revert if the threshold is not met:
In contrast, splitRewards
does not enforce the threshold, making it the primary target for exploitation.
An attacker observes that the splitRewards function is unprotected.
The attacker calls splitRewards repeatedly, forcing the contract to distribute rewards prematurely.
This action disrupts the reward distribution schedule and could lead to unfair advantages or system instability.
Unauthorized Reward Distribution: Users can trigger reward splitting without authorization or regard for the threshold.
Disruption of Reward Logic: The intended mechanism to accumulate rewards before distribution is undermined.
Inefficient Operations: Frequent, unauthorized reward splits can lead to increased gas costs and potential performance issues.
Potential for Denial of Service: Excessive calls to splitRewards could congest the network or deplete contract funds due to gas consumption.
Manual code review
Slither
Implement Access Control: Add an access control modifier such as onlyController
or onlyOwner to the splitRewards
function to restrict its usage to authorized entities.
Consolidate Reward Functions: Consider merging performUpkeep
and splitRewards
into a single function that respects the reward threshold and includes proper access control
Restrict performUpkeep
Access: Add appropriate access control to the performUpkeep
function to prevent unauthorized calls.
Review Access Control Across Contract: Ensure all external functions that can alter contract state or impact core logic have proper access restrictions.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.