Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results
Protocol insolvency
Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
Permanent freezing of funds
Description
Brief/Intro
The lowering quorum poses a significant risk within governance systems, where reducing the quorum requirements could inadvertently render previously unmet proposals executable. This vulnerability arises when the quorum threshold is decreased below its initial value in the future, potentially allowing past proposals that failed to meet the original quorum to be executed. This could lead to unexpected changes in the system, bypassing intended checks and safeguards, and potentially disrupting the integrity of the governance process.
Vulnerability Details
Alchemix utilizes the widely recognized OpenZeppelin governance system, facilitating proposal submission, voting, and execution upon meeting quorum requirements. This governance model, prevalent across various protocols, decentralizes decision-making, avoiding reliance on a single entity and promoting inclusivity. However, a potential pitfall of this model lies in its ability to modify the proposal acceptance quorum in the future. While not inherently a bug, this poses a challenge as it fails to record previous quorums, potentially allowing previously unmet proposals to be executed, circumventing established invariants and requirements.
The contract L2GovernorVotesQuorumFraction is responsible for keeping the aforementioned quorum. If we look at the contracts deeply, we can see there is not a snapshot or data keeping for these quorums. Also, the quorumNumerator can be updated in the future via the mentioned governance model:
function updateQuorumNumerator(uint256 newQuorumNumerator) external virtual onlyGovernance {
_updateQuorumNumerator(newQuorumNumerator);
}
This numerator determines the quorum threshold for proposal acceptance. However, if we reduce this numerator, initially set at 2000, below its current value, previously unmet proposals could potentially be executed. This would compromise past invariants and checks that remain valid.
This means that, If we change the acceptance quorum in the future, and we don't keep a record of the previous quorums, then the not-reaching previous proposals can be executed, bypassing the invariants and requirements.
I want to clarify that this attack differs from what is outlined on the Immunefi page:
Ambiguous Proposal Executions via the TimelockController are acknowledged and a part of the governance management system.
And also:
5.34 Voting Power Threshold Updates
It is similar to this one but completely differs as it doesn't mention the impacts, doesn't share a runnable POC, and also doesn't discuss the ways which is possible.
Impact Details
This complicated attack type may have several impacts on the system:
Transitioning the Timelock contract to one deployed by the attacker, giving them control over crucial functions and proposals.
Cancelling and quietly nullifying important and highly-supported proposals, undermining the governance process.
Triggering the execution of malicious and hazardous proposals, potentially causing severe harm to the system.
Checkpointing the quorum is essential to prevent changes in the quorum from inadvertently transforming previously unsuccessful proposals into successful ones solely due to quorum adjustments.
Or you can update the contracts to match the OpenZeppelin contracts version 4.7.2 or higher. The governance contracts are currently derived from the version 4.5.0: