Skip to content
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

Single-step change of governance address is extremely risky #44

Open
code423n4 opened this issue Sep 15, 2021 · 2 comments
Open

Single-step change of governance address is extremely risky #44

code423n4 opened this issue Sep 15, 2021 · 2 comments
Labels
0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation bug Warden finding duplicate Another warden found this issue

Comments

@code423n4
Copy link
Contributor

Handle

0xRajeev

Vulnerability details

Impact

Single-step change of critical governance address and lack of zero address check is extremely risky. If a zero address or incorrect address (private key not available) is used accidentally, or maliciously changed by a compromised governance account then the entire governance of the protocol is locked forever or lost to an attacker. No governance changes can be made by authorized governance account and protocol will have to be redeployed. The reputation of the protocol will take a huge hit. There may be significant fund lock/loss as well.

Interestingly, this 2-step process is applied to the changing of Strategist address but not Governance address. Governance has more authority in the protocol because it can change the Strategist among other things. So this 2-step should definitely be applied to Governance as well.

Given the magnitude of the impact, i.e. permanent lock of all governance actions, potential lock/loss of funds, and the known/documented failures of wallet opsec, this risk is classified as medium severity.

Proof of Concept

https://github.com/code-423n4/2021-09-yaxis/blob/cf7d9448e70b5c1163a1773adb4709d9d6ad6c99/contracts/v3/Manager.sol#L223-L236

Strategist:
https://github.com/code-423n4/2021-09-yaxis/blob/cf7d9448e70b5c1163a1773adb4709d9d6ad6c99/contracts/v3/Manager.sol#L333-L345
https://github.com/code-423n4/2021-09-yaxis/blob/cf7d9448e70b5c1163a1773adb4709d9d6ad6c99/contracts/v3/Manager.sol#L402-L413

Tools Used

Manual Analysis

Recommended Mitigation Steps

Change of the most critical protocol address i.e. governance should be timelocked and be a 2-step process: approve+claim in two different transactions, instead of a single-step change.

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Warden finding labels Sep 15, 2021
code423n4 added a commit that referenced this issue Sep 15, 2021
@Haz077
Copy link
Collaborator

Haz077 commented Sep 21, 2021

I only agree that there should be zero address checks, which will make this issue duplicated.

@Haz077 Haz077 added the duplicate Another warden found this issue label Sep 21, 2021
@GalloDaSballo
Copy link
Collaborator

Disagree with finding:

  1. Allowing to set to address(0) allows to burn admin keys, which is a good thing for a decentralized protocol
  2. While some protocols prefer a two step governance change, there's nothing inherently wrong with 1-step
    Downgrading to non-critical

@GalloDaSballo GalloDaSballo added 0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation bug Warden finding duplicate Another warden found this issue
Projects
None yet
Development

No branches or pull requests

3 participants