An attacker can prevent the creation of proposals in ExtraordinaryFunding.sol#proposeExtraordinary by front-running the proposal, which will give him the same hash as the correct user desired, and setting endBlock_ to the past, which will invalidate the proposal.
Proof of Concept
This is possible because:
The hash of the proposal has no identifier of who creates it
endBlock_ it is possible to put it in the past to make it invalid:
99: // check proposal length is within limits of 1 month maximum
100: if (block.number + MAX_EFM_PROPOSALLENGTH < endBlock) revert InvalidProposal();
101:
102: uint128 totalTokensRequested = validateCallDatas(targets, values, calldatas);
103:
3. Accordingly, we have the following situation:
1. The correct user wants to create a proposal
2. The attacker front-running this transaction and sends the same proposal, only setting `endBlock_` to the past
3. The transaction of the correct user fails because it is not possible to create two proposal with the same hash
4. A proposal created by an attacker, which is already known, will be invalid because of the past `endBlock_`
```javascript
File: ajna-grants\src\grants\base\ExtraordinaryFunding.sol
139: if (proposal.startBlock > block.number || proposal.endBlock < block.number || proposal.executed) {
140: revert ExtraordinaryFundingProposalInactive();
141: }
The attacker for small funds (transaction fee) prohibits creating new proposals
Tools Used
Manual review
Foundry
Recommended Mitigation Steps
Add creator address to calculate proposal hash: _hashProposal
Lines of code
https://github.com/code-423n4/2023-05-ajna/blob/276942bc2f97488d07b887c8edceaaab7a5c3964/ajna-grants/src/grants/base/ExtraordinaryFunding.sol#L85 https://github.com/code-423n4/2023-05-ajna/blob/276942bc2f97488d07b887c8edceaaab7a5c3964/ajna-grants/src/grants/base/ExtraordinaryFunding.sol#L92 https://github.com/code-423n4/2023-05-ajna/blob/276942bc2f97488d07b887c8edceaaab7a5c3964/ajna-grants/src/grants/base/ExtraordinaryFunding.sol#L100
Vulnerability details
Impact
An attacker can prevent the creation of proposals in
ExtraordinaryFunding.sol#proposeExtraordinary
by front-running the proposal, which will give him the same hash as the correct user desired, and settingendBlock_
to the past, which will invalidate the proposal.Proof of Concept
This is possible because:
endBlock_
it is possible to put it in the past to make it invalid:99: // check proposal length is within limits of 1 month maximum 100: if (block.number + MAX_EFM_PROPOSALLENGTH < endBlock) revert InvalidProposal(); 101: 102: uint128 totalTokensRequested = validateCallDatas(targets, values, calldatas); 103:
The attacker for small funds (transaction fee) prohibits creating new proposals
Tools Used
Recommended Mitigation Steps
_hashProposal
Assessed type
DoS