Detailed description of the impact of this finding.
description: The rewardPerTokenAccumulated function in the provided Solidity code is vulnerable to the exploitation of outdated reward checkpoints in exceptional system states. This vulnerability arises because the function computes rewards based on the rewardPerTokenAccumulatedCheckpoint without updating it in response to changes in the system state that may prevent accurate reward distribution. If the system enters a state where the total staked amount (totalStaked) changes after a shutdown or similar exceptional condition, users could manipulate their rewards by transferring stakes and claiming rewards that are not rightfully theirs, based on the stale rewardPerTokenAccumulatedCheckpoint. This can result in unauthorized extraction of unclaimed yield, potentially leading to unjust enrichment at the expense of the protocol and its rightful users. The root cause is the absence of checks and balances to ensure that the checkpoint data reflects the current system state, and the maximum impact could be the theft or freezing of unclaimed yield, undermining the integrity of the reward distribution mechanism.
Finding Recommendation:
To address the vulnerability identified in the code snippet, it is recommended to implement a mechanism that ensures the rewardPerTokenAccumulatedCheckpoint is updated consistently, even in special states where checkpoints are not normally updated. This could involve adding a check within the function to update the checkpoint if certain conditions are met, or implementing a separate function to handle checkpoint updates. Additionally, consider restricting user participation transfers when the system is in the special state to prevent exploitation of outdated data. Regularly auditing and monitoring the code for such vulnerabilities is also recommended to maintain the security and integrity of the protocol.
Lines of code
https://github.com/code-423n4/2024-02-uniswap-foundation/blob/main/src/UniStaker.sol#L229-L234
Vulnerability details
Impact
Detailed description of the impact of this finding. description: The
rewardPerTokenAccumulated
function in the provided Solidity code is vulnerable to the exploitation of outdated reward checkpoints in exceptional system states. This vulnerability arises because the function computes rewards based on therewardPerTokenAccumulatedCheckpoint
without updating it in response to changes in the system state that may prevent accurate reward distribution. If the system enters a state where the total staked amount (totalStaked
) changes after a shutdown or similar exceptional condition, users could manipulate their rewards by transferring stakes and claiming rewards that are not rightfully theirs, based on the stalerewardPerTokenAccumulatedCheckpoint
. This can result in unauthorized extraction of unclaimed yield, potentially leading to unjust enrichment at the expense of the protocol and its rightful users. The root cause is the absence of checks and balances to ensure that the checkpoint data reflects the current system state, and the maximum impact could be the theft or freezing of unclaimed yield, undermining the integrity of the reward distribution mechanism.Proof of Concept
Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept. https://github.com/code-423n4/2024-02-uniswap-foundation/blob/main/src/UniStaker.sol#L229-L234
Tools Used
Recommended Mitigation Steps
Finding Recommendation: To address the vulnerability identified in the code snippet, it is recommended to implement a mechanism that ensures the
rewardPerTokenAccumulatedCheckpoint
is updated consistently, even in special states where checkpoints are not normally updated. This could involve adding a check within the function to update the checkpoint if certain conditions are met, or implementing a separate function to handle checkpoint updates. Additionally, consider restricting user participation transfers when the system is in the special state to prevent exploitation of outdated data. Regularly auditing and monitoring the code for such vulnerabilities is also recommended to maintain the security and integrity of the protocol.Assessed type
Timing