Olympus DAO contest - pedroais's results

Version 3 of Olympus protocol, a decentralized floating currency.

General Information

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

Olympus DAO

Findings Distribution

Researcher Performance

Rank: 37/147

Findings: 1

Award: $514.46

๐ŸŒŸ Selected for report: 0

๐Ÿš€ Solo Findings: 0

Findings Information

๐ŸŒŸ Selected for report: d3e4

Also found by: Aymen0909, pedroais

Labels

bug
duplicate
2 (Med Risk)

Awards

514.4616 DAI - $514.46

External Links

Lines of code

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

Vulnerability details

Impact

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.

Proof of Concept

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

https://github.com/code-423n4/2022-08-olympus/blob/b5e139d732eb4c07102f149fb9426d356af617aa/src/policies/Governance.sol#L218

-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

https://github.com/code-423n4/2022-08-olympus/blob/b5e139d732eb4c07102f149fb9426d356af617aa/src/policies/Governance.sol#L244

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

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax ยฉ 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter