You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 12, 2025. It is now read-only.
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
Rewards in MlumStaking are distributed unfairly not taking into consideration the time someone has been locked.
Vulnerability Detail
In MlumStaking contract, as stated in the docs rewards will be distributed every few days(see here). However, the contract does not take into consideration the time that someone has been locked for between the reward distrbutions and this opens the door to some attacks making the rewards to be distributed unfairly. Also, the contract allows users to create StakingPosition with 0 lockDuration which means that this position is available to be withdrawn anytime the user wants and just the multiplier will be 0. This can cause serious problems in the reward distribution process since someone can time the updatePool call and create a position with 0 lockDuration, minutes/hours before the reward distribution and then instantly withdraw it after the updatePool call.
Impact
This vulnerability leads to unfair reward distribution since an attacker can get a huge portion of the rewards without having the appropriate time commitment. As a result, users and MLUM stakers will get less rewards than they should due to the fact that the attacker locked some minutes/hours before the distribution and then instantly withdraw after the updatePool call.
Proof of concept
This PoC demonstrates the scenario where someone frontruns the updatePool function by creating a StakingPosition with lockDuration set to 0 and then backruns it by calling withdrawFromPosition instantly. However, this can happen, also, with some time delay and the attacker create a StakingPosition some minutes/hours before the reward distribution and then instantly withdraw it after the updatePool call. To understand better this vulnerability, add this test in the MlumStaking.sol file and run forge test --mt test_attackWithFrontrunningInMintRewards :
sherlock-admin2
changed the title
Acidic Sky Zebra - Rewards in MlumStaking are distributed unfairly not taking into consideration the time someone has been locked.
zarkk01 - Rewards in MlumStaking are distributed unfairly not taking into consideration the time someone has been locked.
Jul 30, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
zarkk01
High
Rewards in
MlumStaking
are distributed unfairly not taking into consideration the time someone has been locked.Vulnerability Detail
In
MlumStaking
contract, as stated in the docs rewards will be distributed every few days(see here). However, the contract does not take into consideration the time that someone has been locked for between the reward distrbutions and this opens the door to some attacks making the rewards to be distributed unfairly. Also, the contract allows users to createStakingPosition
with 0lockDuration
which means that this position is available to be withdrawn anytime the user wants and just the multiplier will be 0. This can cause serious problems in the reward distribution process since someone can time theupdatePool
call and create a position with 0lockDuration
, minutes/hours before the reward distribution and then instantly withdraw it after theupdatePool
call.Impact
This vulnerability leads to unfair reward distribution since an attacker can get a huge portion of the rewards without having the appropriate time commitment. As a result, users and
MLUM
stakers will get less rewards than they should due to the fact that the attacker locked some minutes/hours before the distribution and then instantly withdraw after theupdatePool
call.Proof of concept
This PoC demonstrates the scenario where someone frontruns the
updatePool
function by creating aStakingPosition
withlockDuration
set to 0 and then backruns it by callingwithdrawFromPosition
instantly. However, this can happen, also, with some time delay and the attacker create aStakingPosition
some minutes/hours before the reward distribution and then instantly withdraw it after theupdatePool
call. To understand better this vulnerability, add this test in theMlumStaking.sol
file and runforge test --mt test_attackWithFrontrunningInMintRewards
:Code Snippet
https://github.com/sherlock-audit/2024-06-magicsea/blob/main/magicsea-staking/src/MlumStaking.sol#L354
https://github.com/sherlock-audit/2024-06-magicsea/blob/main/magicsea-staking/src/MlumStaking.sol#L574
Tool used
Manual Review
Recommendation
Consider checking how much time has someone been locked for an distribute the rewards accordingly.
Duplicate of #74
The text was updated successfully, but these errors were encountered: