-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GuildVetoGovernor
's timelock doesn't need DAO proposal to be changed
#740
Comments
As per the docs, Governor is trusted with the actions. |
0xSorryNotSorry marked the issue as insufficient quality report |
Governor is trusted, and this issue is an instance of Governor's centralization risk ([M-01] Centralization risk for privileged functions) |
Trumpero marked the issue as unsatisfactory: |
Hi @Trumpero, I believe the context of this submission was not fully understood during the presort phase. There are two possible scenarios covered. I do agree that admin actions are trusted and that them being able to change the timelock of However, the issue here is bigger than that. While it's possible for them to do it, it's not possible for them to do the same with I've covered both sides of the coin in the submission. I believe both |
Forwarding this statement from contest docs
The Governor role in the protocol is GuildTimelockController, which serves as the timelock for GuildGovernor. Therefore, updating the timelock of GuildVetoGovernor is similar with GuildGovernor and already decentralized. |
Lines of code
https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/governance/GuildVetoGovernor.sol#L99-L102
Vulnerability details
Impact
GuildVetoGovernor
andGuildGovernor
can point to different timelock contracts. This happens due to a possible state diversion in the code where changing the timelock reference contract in one place doesn't affect the other. This could result in voters vetoing changes in the wrong timelock without realizing it.Proof of Concept
Currently, in order to update
GuildVetoGovernor
's timelock contract, someone who isGOVERNOR
needs to just call theupdateTimelock
function. This action is instantaneous and doesn't require creating a proposal.To change
GuildGovernor
's timelock though, one needs to create a DAO proposal and pass the quorum of votes needed in order to get it through. Admins can't change it directly.The behavior is forced by the
onlyGovernance
modifier (OZ'sGovernor.sol
):POC (use
GuildVetoGovernor.t.sol
):This causes the following issues:
GuildVetoGovernor
butGuildGovernor
isn't pointing to the new one. This may cause users unaware of this to veto a proposal from the new timelock without realizing it's not associated with the DAO's current timelock.GuildVetoGovernor
changes while the DAO's one hasn't, then they lose the ability to veto in the old timelock. The old one could still execute already queued changes that they didn't like.Tools Used
Manual Analysis
Recommended Mitigation Steps
updateTimelock
fromGuildVetoGovernor
. Think of a way to bulk-update both when such a proposal is created. Maybe through some code override inTimelockController
, or maybe a separate function inGuildGovernor
that is specifically meant for creating such proposals. Then, strip the old Timelock from its roles so it can't execute actions anymore.GuildGovernor
as well so both can be updated by an admin at the same time, in order to avoid the desynchronization issue.Assessed type
Governance
The text was updated successfully, but these errors were encountered: