Closed code423n4 closed 1 year ago
hansfriese marked the issue as unsatisfactory: Out of scope
hansfriese marked the issue as satisfactory
hansfriese marked the issue as duplicate of #280
hansfriese changed the severity to QA (Quality Assurance)
hansfriese marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2023-03-neotokyo/blob/dfa5887062e47e2d0c801ef33062d44c09f6f36e/contracts/staking/NeoTokyoStaker.sol#L1320
Vulnerability details
Impact
While out of scope, it is important to note, that the function
getPoolReward()
which is used to calculate and mint rewards can only work if thepool.rewardWindows[0].startTime == 0
and will revert with index underflow otherwise:https://github.com/code-423n4/2023-03-neotokyo/blob/dfa5887062e47e2d0c801ef33062d44c09f6f36e/contracts/staking/NeoTokyoStaker.sol#L1320
The pool's window
startTime
is configured viaconfigurePools()
which allows to set the first windowstartTime
to a positive value:https://github.com/code-423n4/2023-03-neotokyo/blob/dfa5887062e47e2d0c801ef33062d44c09f6f36e/contracts/staking/NeoTokyoStaker.sol#L1837
A positive value of the first window means that the pool's rewards should start from some specific timestamp and not from the begnning of time. This reasoning may be used by an admin to set the first window startTime to a positive value, thus breaking the contract temporarily until pools are reconfigured again.
Proof of Concept
x
Tools Used
x
Recommended Mitigation Steps
Add a requirement in
configurePools()
that the first windowstartTime
should always be zero: