Currently, block.timestamp < rewardData[_rewardsToken].periodFinish, meaning for a 30-day reward period with 1000 tokens per day reward period, currently we are at the 20th day, so 10 * 1000 tokens are yet to stream.
Now call depositReward with 0 rewards, which will keep the reward amount same, but it will increase the periodFinish to now + 30 days, so reward rate becomes (10 * 1000 + 0 ) / 30 = 333 tokens per day.
So there is a sudden 1/3 rate decrease and stakers will leave if this happens. Also, you can repeatedly call everyday and keep on deflating the reward rate.
so the same rewards that were about to stream for the remaining 10 days were elongated to 30 more days, so stakers have to wait a long time to claim their rewards.
This is an issue, deflating reward rates, so stakers might exit seeing the reward APRs. Even if after 10 days a new reward is deposited by YDL which is done every month end, those 10 days rewards are made 1/3 rd slower by elongating it to 30 days.
Attack path: 2
It is 5 days away from distribution in YDL. So the keeper will call to deposit rewards in 5 more days by calling ZivoeYDL.distributeYield.
Now, an attacker can call deposit reward with a very low value and it will deflate the reward rate due to same numerator but big denominator, After 5 days, YDL will distribute rewards further, making the reward duration very high. So genuinely, it should be x + 30 days, but now it's 5 + x + 30 days, the same rewards but spread out in extra days, discouraging stakers to exit.
This cannot be fixed by reward rate and blance checks, or input validation to be rewards > 0, atatcker will still do this attack even if the cost is 1000$. So the recommendation is to make this callable only by YDL contract or ZVL .
Another impact of causing DOS on YDL reward distribution is,
1. There's a missing check that reward rate <= rewardbalance/reward period that will be added by Zivoe related to other issue ex: synthetix/contracts/StakingRewards.sol#L127.
And if this is added, someone can call deposit reward legitimately with 0 as reward, and it will decrese the reward rate the same reward token balance, and it will trigger this revert, and whole ZivoeYDL.distributeYield will fail making the YDL distribution revrting to cause DOS.
Impact
DOS to yield distribution. And reward emissions can be made very slow by increasing the reward duration.
Ironsidesec
high
ZivoeRewardsVesting
: reward rate can be deflatedSummary
Issue happens on
ZivoeRewardsVesting
contract's depositRewardroot cause: missing access control to
depositReward
Impact :Vulnerability Detail
https://github.com/sherlock-audit/2024-03-zivoe/blob/01e00e6f27b58392a6fa0b82c84a46a783a0df3c/zivoe-core-foundry/src/ZivoeRewardsVesting.sol#L352
reward rate = reward balance / reward duration.
Attack path: 1
Currently,
block.timestamp < rewardData[_rewardsToken].periodFinish
, meaning for a 30-day reward period with 1000 tokens per day reward period, currently we are at the 20th day, so 10 * 1000 tokens are yet to stream.Now call
depositReward
with 0 rewards, which will keep the reward amount same, but it will increase theperiodFinish
tonow + 30 days
, so reward rate becomes (10 * 1000 + 0 ) / 30 = 333 tokens per day.So there is a sudden 1/3 rate decrease and stakers will leave if this happens. Also, you can repeatedly call everyday and keep on deflating the reward rate.
so the same rewards that were about to stream for the remaining 10 days were elongated to 30 more days, so stakers have to wait a long time to claim their rewards.
This is an issue, deflating reward rates, so stakers might exit seeing the reward APRs. Even if after 10 days a new reward is deposited by YDL which is done every month end, those 10 days rewards are made 1/3 rd slower by elongating it to 30 days.
Attack path: 2
This cannot be fixed by reward rate and blance checks, or input validation to be rewards > 0, atatcker will still do this attack even if the cost is 1000$. So the recommendation is to make this callable only by YDL contract or ZVL .
Another impact of causing DOS on YDL reward distribution is, 1. There's a missing check that
reward rate <= rewardbalance/reward period
that will be added by Zivoe related to other issue ex: synthetix/contracts/StakingRewards.sol#L127.And if this is added, someone can call deposit reward legitimately with 0 as reward, and it will decrese the reward rate the same reward token balance, and it will trigger this revert, and whole ZivoeYDL.distributeYield will fail making the YDL distribution revrting to cause DOS.
Impact
DOS to yield distribution. And reward emissions can be made very slow by increasing the reward duration.
Code Snippet
https://github.com/sherlock-audit/2024-03-zivoe/blob/01e00e6f27b58392a6fa0b82c84a46a783a0df3c/zivoe-core-foundry/src/ZivoeRewardsVesting.sol#L352
Tool used
Manual Review
Recommendation
Add access control,
depositReward
to only callable by YDL contract.https://github.com/sherlock-audit/2024-03-zivoe/blob/01e00e6f27b58392a6fa0b82c84a46a783a0df3c/zivoe-core-foundry/src/ZivoeRewardsVesting.sol#L352
Duplicate of #11