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

changeDAO should be a two-step process in Vader.sol #162

Open
code423n4 opened this issue Apr 27, 2021 · 2 comments
Open

changeDAO should be a two-step process in Vader.sol #162

code423n4 opened this issue Apr 27, 2021 · 2 comments
Labels
2 (Med Risk) bug Something isn't working disagree with severity This doesn't seem right sponsor confirmed

Comments

@code423n4
Copy link
Collaborator

Handle

0xRajeev

Vulnerability details

Impact

changeDAO() updates DAO address in one-step. If an incorrect address is mistakenly used (and voted upon) then future administrative access or recovering from this mistake is prevented because onlyDAO modifier is used for changeDAO(), which requires msg.sender to be the incorrectly used DAO address (for which private keys may not be available to sign transactions).

Reference: See finding #6 from Trail of Bits audit of Hermez Network: https://github.com/trailofbits/publications/blob/master/reviews/hermez.pdf

Proof of Concept

https://github.com/code-423n4/2021-04-vader/blob/3041f20c920821b89d01f652867d5207d18c8703/vader-protocol/contracts/Vader.sol#L192-L196

Tools Used

Manual Analysis

Recommended Mitigation Steps

Use a two-step process where the old DAO address first proposes new ownership in one transaction and a second transaction from the newly proposed DAO address accepts ownership. A mistake in the first step can be recovered by granting with a new correct address again before the new DAO address accepts ownership. Ideally, there should also be a timelock enforced before the new DAO takes effect.

@code423n4 code423n4 added 3 (High Risk) bug Something isn't working labels Apr 27, 2021
code423n4 added a commit that referenced this issue Apr 27, 2021
@strictly-scarce
Copy link
Collaborator

A lot has to go wrong to get to this point, so disagree with severity (funds not at risk).

Two step-process seems wise though.

@dmvt
Copy link
Collaborator

dmvt commented May 25, 2021

Risk lowered because of the extremely low probability

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) bug Something isn't working disagree with severity This doesn't seem right sponsor confirmed
Projects
None yet
Development

No branches or pull requests

3 participants