fullyallocated
commented
2 years ago There is a DDoS attack here, but it's conditional. First, the user would need to have enough endorsements to break the activation threshold—20% of the total voting supply—so it's more of an economic/parameterization exploit than a mechanical one.
With that being said, if the VOTES token were a liquid, unlocked token, a malicious actor can sybil the endorsements, but in production we will have a warmup/cooldown period to prevent sybil voting on governance endorsements.
bahurum
0xean
Lines of code
https://github.com/code-423n4/2022-08-olympus/blob/main/src/policies/Governance.sol#L159-L176 https://github.com/code-423n4/2022-08-olympus/blob/main/src/policies/Governance.sol#L180-L201
Vulnerability details
Impact
A user can submit multiple proposals and then endorse each one of them to be able to activate them, and because the Governance contract allow only one active proposal, this user will be able to always activate his proposals and thus not allowing any other proposals to be activated.
Proof of Concept
As you can see the submitProposal function allow a user to submit infinite amount of proposals, and the endorseProposal function allow the user to endorse multiple proposals at the same time (including his own proposals) and thus the proposer is always able to activate his proposals Thus by submitting multiple proposals the user can endorse them and activate them one at the time and thus blocking the governance process
Tools Used
Manual audit
Recommended Mitigation Steps
Add a check in the endorseProposal function to not allow the submitter to endorse his own proposals and by doing so he will not be able to activate unless the governance community endorse his proposals