Platform: Code4rena
Start Date: 25/08/2022
Pot Size: $75,000 USDC
Total HM: 35
Participants: 147
Period: 7 days
Judge: 0xean
Total Solo HM: 15
Id: 156
League: ETH
Rank: 37/147
Findings: 1
Award: $514.46
๐ Selected for report: 0
๐ Solo Findings: 0
https://github.com/code-423n4/2022-08-olympus/blob/b5e139d732eb4c07102f149fb9426d356af617aa/src/policies/Governance.sol#L218 https://github.com/code-423n4/2022-08-olympus/blob/b5e139d732eb4c07102f149fb9426d356af617aa/src/policies/Governance.sol#L244
An account controlling enough voting percentage to endorse a proposal can block an unwanted proposal from being activated. This can be done by frontrunning or by paying more for gas. There can only be one concurrent activated proposal so there is a race condition on the first to activate it.
This can be done by an account or multiple colluding accounts with the common interest of blocking a proposal. In a tight voting scenario, the minority will be incentivized to exploit this vulnerability to block the majority proposal.
I think this issue is of critical severity since actors could be incentivized to DDOS if the proposal hurts their economic interest in some other way and could block olympusDAO from taking quick governance action and attempting against the interest of the DAO majority. This isn't a simple blockage of protocol functionality since blocking governance could freeze the DAO from acting, changing modules in case of hack / theft , updating contracts, and acting on treasury funds.
A majority wants to pass a proposal that a minority of at least 20% of voting power doesnโt want.
-The attacker t calls submitProposal()
-One or multiple accounts with enough votes to pass the endorsement threshold (20% hard coded) endorses the proposal
-Once the proposal is endorsed the first activated proposal will be voted on. The first one to call activateProposal() will have his proposal activated and timelocked and there can only be one activatedProposal(). While the proposal is being voted on the attackers can endorse another proposal and be the firsts to call activate() to DDOS governance and block the majority from passing proposals
This problem is produced by the requirement of having max 1 activated proposal. This is fixable by removing the race condition on activateProposal() and allow multiple active proposals to exist or by only allowing the proposal with more endorsment to be activated.
This second solution could be a good improvement to the voting system and remove this potential vulnerability.
#0 - bahurum
2022-09-02T13:32:14Z
Duplicate of #375
#1 - fullyallocated
2022-09-02T20:42:45Z
Duplicate of #239
#2 - 0xean
2022-09-19T17:17:48Z
duplicate of #375