Incorrect voting due to increment logic of proposal IDs
Summary
Incorrect voting process related to GovernorAlpha contract logic due to increment logic of proposal IDs.
Severity
Medium
Vulnerability Detail
There is castVote and castVoteBySig functions in the GovernorAlpha contract. The functions accept the proposalId which does not contain any information about the proposal itself. As a result, transactions of users can be front-runned to enforce them to vote for the proposal with the same proposalId he doesn't want to vote on.
As an example let's consider the following scenario:
Someone (let's call him Bob) sends a propose transaction to the mempool. After that someone else (let's call him Charlie) sends a transaction castVote with proposalId equal to the expected id of the proposal. Then the malicious user can send a transaction with a higher fee that creates a proposal that has the same proposalId but different content. This transaction most likely will be included in the block before the transaction from Bob so Charlie will vote for the proposal he doesn't want to vote on.
So, the order of transactions may be the following:
malicious user propose transaction
Charlie's castVote transaction
Bob's propose transaction
Note, that it is not necessarily for Charlie to send accept transaction to mempool when Bob's propose transaction is not included in the block to get under attack. That also can happen while chain reorg.
Impact
The incorrect voting process and, as result, an incorrect result of voting.
Consider adding into the newProposalId calculation logic some special value based on the proposal-related parameters (for example hash of the proposal content).
vlad
medium
Incorrect voting due to increment logic of proposal IDs
Summary
Incorrect voting process related to
GovernorAlpha
contract logic due to increment logic of proposal IDs.Severity
Medium
Vulnerability Detail
There is
castVote
andcastVoteBySig
functions in theGovernorAlpha
contract. The functions accept theproposalId
which does not contain any information about the proposal itself. As a result, transactions of users can be front-runned to enforce them to vote for the proposal with the sameproposalId
he doesn't want to vote on.As an example let's consider the following scenario:
Someone (let's call him Bob) sends a
propose
transaction to the mempool. After that someone else (let's call him Charlie) sends a transactioncastVote
withproposalId
equal to the expected id of the proposal. Then the malicious user can send a transaction with a higher fee that creates a proposal that has the sameproposalId
but different content. This transaction most likely will be included in the block before the transaction from Bob so Charlie will vote for the proposal he doesn't want to vote on.So, the order of transactions may be the following:
propose
transactioncastVote
transactionpropose
transactionNote, that it is not necessarily for Charlie to send
accept
transaction to mempool when Bob'spropose
transaction is not included in the block to get under attack. That also can happen while chain reorg.Impact
The incorrect voting process and, as result, an incorrect result of voting.
Code Snippet
Tool used
Manual Review
Recommendation
Consider adding into the
newProposalId
calculation logic some special value based on the proposal-related parameters (for example hash of the proposal content).