Submitted by TresDelinquentes, also found by Pechenite, Arz, Neon2835, J4X, D1r3Wolf, 3docSec, Bauchibred, chainsnake, and adeolu
The contract implements a state variable minContribution, which enforces a minimum contribution to the crowdfund.
An issue occurs when minContribution > maxTotalContribution - minTotalContribution. The protocol team even accounted for such a case, but they assumed that minTotalContribution can always be reached, so a host can then call finalize and finalize the crowdfund early, but that isnt the case.
Lets look at an example:
(Keep in mind that the values can vary, this is just an example).
minContribution = 2e18
minTotalContribution = 9e18
maxTotalContribution = 10e18
Then we apply this check, which will always revert. We cant send less than minContribution and even if we send more, after we apply the refund amount will always be smaller than minContribution.
At this point the crowdfund is stuck in limbo, minTotalContribution and maxTotalContribution can never be reached. Because minTotalContribution isnt reached, the host cant finalize the crowdfund early. Thus, the crowdfund will eventually expire and be lost.
Users will be able to call refund only after the crowdfund is Lost. The DoS will last as long as the duration of the crowdfund. If duration = 14 days, then the users will recover their funds after 14 days.
Note that if emergencyDisabled = true, the DAO wont be able to retrieve their funds through emergencyExecute and the users will have to wait until the crowdfund is lost.
This issue can occur without anyone being malicious, although a malicious user can set up the correct state more effectively.
Paste the following inside test/crowdfund/InitialETHCrowdfund.t.sol in contract InitialETHCrowdfundTest and run forge test --mt test_MinTotalContributionsProblem -vvvv:
Foundry
Possible solution is not to allow minContributions > maxTotalContributions - minTotalContributions. This mitigation may not be the best long-term solution, so we suggest exploring different mitigation.
DoS
0xble (Party) confirmed and commented via duplicate issue #453:
0xble (Party) commented via duplicate issue #453:
gzeon (judge) commented via duplicate issue #453:
J4X (warden) commented via duplicate issue #453:
gzeon (judge) commented via duplicate issue #453:
