Lucene search

K
code423n4Code4renaCODE423N4:2022-01-BEHODLER-FINDINGS-ISSUES-296
HistoryFeb 02, 2022 - 12:00 a.m.

Lack of access control in the parameterize function of proposal contracts

2022-02-0200:00:00
Code4rena
github.com
4

Handle

shw

Vulnerability details

Impact

Most of the proposal contracts have a parameterize function for setting the proposal parameters, and these functions are protected only by the notCurrent modifier. When the proposal is proposed through a lodgeProposal transaction, an attacker can front-run it, modify the proposal parameters, and let the community vote it down. As a result, the person proposing loses his fate deposit.

Proof of Concept

  1. A benign user Alice wants to make a proposal, so she deploys one of the proposal contracts and sets the intended parameters. Her proposal is approved by the ProposalFactory and is ready to be proposed.
  2. Alice calls the lodgeProposal function of ProposalFactory to propose her proposal.
  3. An attacker Bob, who listens to the mempool, notices Alice’s transaction and front-runs it. He calls the parameterize function to change the parameters to undesirable ones.
  4. Alice’s proposal becomes the current proposal. However, the community rejects the proposal because of the changed parameters, causing Alice to lose her deposit.

Referenced code:
DAO/Proposals/BurnFlashStakeDeposit.sol#L25-L37
DAO/Proposals/SetAssetApprovalProposal.sol#L21-L24
DAO/Proposals/ToggleWhitelistProposalProposal.sol#L22-L28
DAO/Proposals/UpdateMultipleSoulConfigProposal.sol#L40-L61
DAO/Proposals/WithdrawERC20Proposal.sol#L26-L32
DAO/ProposalFactory.sol#L74-L78

Recommended Mitigation Steps

Only allow the creator of the proposal to modify the parameters.


The text was updated successfully, but these errors were encountered:

All reactions