A malicious actor could potentially exploit the PositiveDepositChange revert statement in the performUpkeep function by manipulating the deposit change of a strategy to be non-negative (zero or positive). Since the performUpkeep function iterates through the list of strategies to update and checks if their deposit change is negative, if any strategy reports a non-negative deposit change, the function will revert with the PositiveDepositChange error.
To carry out this exploit, the attacker would need to influence its deposit change calculation. This could be done by:
Directly manipulating the strategy if the attacker has the ability to interact with it in a way that affects the deposit change calculation.
Indirectly affecting the external dependencies that the strategy relies on to calculate the deposit change.
By changing at any one strategy to have a non-negative deposit change after the _performData has been created by checkUpkeep or other function, the attacker could prevent the performUpkeep function from successfully executing, thereby disrupting the normal operation of the staking pool and potentially cause financial damage or loss of confidence in the system. If this could be executed over multiple epochs of ccip calls to performUpkeep calls, strategies that need updating due to a negative rebase could continue to deteriorate.
The consequence of such an attack would be the inability to execute the performUpkeep
function, leading to a failure in updating rewards, particularly after a negative rebase. This disruption could significantly impair the normal functioning of the staking pool.
It is important to note that the susceptibility to this vulnerability is contingent on the specific implementation details of your CCIP integration, including the sequence and methodology employed in function calls. Additionally, each strategy contract incorporated into the system, as well as any updates to CCIP controllers, could inadvertently introduce new vectors for exploitation that may remain undetected. This may very well not affect the contract at launch, but could become an exploit over the lifetime of the contract.
Manual Review
The performUpkeep function should not revert if the getDepositChange function returns greater than or equal to zero. It is recommended that the function be refactored to allow execution to continue with strategies that result in a negative rebase. Additionally, it is advisable to implement an event emission to signal when a positive return condition occurs. This approach will enhance the robustness and transparency of the contract's operational logic.
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.