Closed sherlock-admin4 closed 5 months ago
@MxAxM, please share the rejection response.
@MxAxM, please share the rejection response.
Can you provide a PoC for this issue ?
@MxAxM, please share the rejection response.
Can you provide a PoC for this issue ?
Tested a POC, it works as intended. the fair delay is between 0 and max delay only. Issue should be kept invalid.
Ran 1 test for test/foundry/DelayTest.t.sol:ContinuousVestingMerkleDistributorTest
[PASS] test_Delay() (gas: 22577)
Logs:
3048
3600
405972677036361921723245786865634172126647928
Traces:
[22577] ContinuousVestingMerkleDistributorTest::test_Delay()
├─ [8010] 0x815F194fa08ECeae9A97eb5714D2A95F51680Cc6::getFairDelayTime(0x36A35fB10d9d273da615f4b658829901326e0d00) [staticcall]
│ ├─ [5338] ContinuousVestingMerkleDistributor::getFairDelayTime(0x36A35fB10d9d273da615f4b658829901326e0d00) [delegatecall]
│ │ └─ ← [Return] 3048
│ └─ ← [Return] 3048
├─ [0] console::log(3048) [staticcall]
│ └─ ← [Stop]
├─ [3684] 0x815F194fa08ECeae9A97eb5714D2A95F51680Cc6::maxDelayTime() [staticcall]
│ ├─ [3518] ContinuousVestingMerkleDistributor::maxDelayTime() [delegatecall]
│ │ └─ ← [Return] 3600
│ └─ ← [Return] 3600
├─ [0] console::log(3600) [staticcall]
│ └─ ← [Stop]
├─ [1398] 0x815F194fa08ECeae9A97eb5714D2A95F51680Cc6::distancePerSecond() [staticcall]
│ ├─ [1232] ContinuousVestingMerkleDistributor::distancePerSecond() [delegatecall]
│ │ └─ ← [Return] 405972677036361921723245786865634172126647928 [4.059e44]
│ └─ ← [Return] 405972677036361921723245786865634172126647928 [4.059e44]
├─ [0] console::log(405972677036361921723245786865634172126647928 [4.059e44]) [staticcall]
│ └─ ← [Stop]
└─ ← [Return]
Ironsidesec
high
maxDelay
can be breached and causes DOS to most claimersSummary
FairQueueInitializable.getFairDelayTime
gives a notice on L58 below, that the delay time will be between[0, maxDelay]
. But for over 50% of the users, it will be > max delay time due to the delay computing time depending on user's address and not accounting maxdelay modulo(%). All it has to do to solve is, do a modulo bymaxDelay
. so (getFairDelayTime() % maxDelay) and now it will be < maxDelay all the time and no DOS to the claimers.Impact : DOS to half the users. Likelihood : whenever claim is called, so all the time.
Look at the way delay time is computed, a
randomValue
anddistancePerSecond
is computed when deployment and they are used on L78 and L82 below. This accounting doesn't guarantee that the delay time will be < max delaytime.https://github.com/sherlock-audit/2024-05-tokensoft-distributor-contracts-update/blob/67edd899612619b0acefdcb0783ef7a8a75caeac/contracts/packages/hardhat/contracts/claim/factory/FairQueueInitializable.sol#L56
Vulnerability Detail
DOS occurs in both
TrancheVesting
andContinuousVesting
.TrancheVesting
, imagine a 3 tranch vesting 33% each for 3 months straight. And assuming max delay time is 5 days to combat gas wars. the delay time can be so high as it doesn't account to do (% maxdelay), and the vested fraction will return 0 due to high delay because the delayed time is < first tranche's time, and claimable == 0 leads to 0 claimable amount. And as a user this is a DOS to me, most of the time. And I have to wait till my delayed time crosses each tranche's time. If thedelayed time - current
is < max delay, then it is intended and not a DOS. But delaying more than maxdelay is DOS.Same issue on
ContinuousVesting
, the delayed time will be < cliff most of the times even if the current time went > end, because the delayed time is so small with huge delay > maxdelay. Example: start on Jan 1, cliff on Feb 1, end on may 1 and max delay of 5 days. Even if the current time is on June 1, the delayed time iis made so small it goes to the previous year the maxdelay time of 5 days accounting is missing.https://github.com/sherlock-audit/2024-05-tokensoft-distributor-contracts-update/blob/67edd899612619b0acefdcb0783ef7a8a75caeac/contracts/packages/hardhat/contracts/claim/abstract/PerAddressTrancheVesting.sol#L41
https://github.com/sherlock-audit/2024-05-tokensoft-distributor-contracts-update/blob/67edd899612619b0acefdcb0783ef7a8a75caeac/contracts/packages/hardhat/contracts/claim/abstract/PerAddressContinuousVesting.sol#L29
Impact
DOS to half the claimers of both
TrancheVesting
andContinuousVesting
so High impact and high likelihood.Code Snippet
https://github.com/sherlock-audit/2024-05-tokensoft-distributor-contracts-update/blob/67edd899612619b0acefdcb0783ef7a8a75caeac/contracts/packages/hardhat/contracts/claim/factory/FairQueueInitializable.sol#L56
https://github.com/sherlock-audit/2024-05-tokensoft-distributor-contracts-update/blob/67edd899612619b0acefdcb0783ef7a8a75caeac/contracts/packages/hardhat/contracts/claim/abstract/PerAddressTrancheVesting.sol#L41
https://github.com/sherlock-audit/2024-05-tokensoft-distributor-contracts-update/blob/67edd899612619b0acefdcb0783ef7a8a75caeac/contracts/packages/hardhat/contracts/claim/abstract/PerAddressContinuousVesting.sol#L29
Tool used
Manual Review
Recommendation
https://github.com/sherlock-audit/2024-05-tokensoft-distributor-contracts-update/blob/67edd899612619b0acefdcb0783ef7a8a75caeac/contracts/packages/hardhat/contracts/claim/factory/FairQueueInitializable.sol#L79