code-423n4 / 2024-02-uniswap-foundation-findings

2 stars 3 forks source link

Potential Exploitation of Outdated Reward Checkpoint in Staking Reward Calculation #193

Closed c4-bot-9 closed 8 months ago

c4-bot-9 commented 9 months ago

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 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.

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

c4-judge commented 8 months ago

MarioPoneder marked the issue as unsatisfactory: Insufficient proof