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

Critical uberOwner address changes should be a two-step process #105

Open
code423n4 opened this issue Jun 16, 2021 · 2 comments
Open

Critical uberOwner address changes should be a two-step process #105

code423n4 opened this issue Jun 16, 2021 · 2 comments
Labels
2 (Med Risk) bug Something isn't working

Comments

@code423n4
Copy link
Contributor

Handle

0xRajeev

Vulnerability details

Impact

As specified, uberOwners of Factory, Orderbook and Treasury have the highest privileges in the system because they can upgrade contracts of market, Nfthub, order book, treasury, token and factory which form the critical components of the protocol.

The contracts allow for uberOwners to be changed to a different address from the contract owner/deployer using the changeUberOwner() function which is callable by the current uberOwner. While this function checks for zero-address, there is no validation of the new address being correct. If the current uberOwner incorrectly uses an invalid address for which they do not have the private key, then the system gets locked because the uberOwner cannot be corrected and none of the other functions that require uberOwner caller can be executed.

Impact: The current uberOwner uses a non-zero but incorrect address as the new uberOwner. This gets set and now the system is locked and none of the uberOwner-only callable functions are callable. This error cannot be fixed either and will require redeployment of contracts which will mean that all existing markets have to be terminated. The system will have to be shut and restarted completely from scratch which will take a reputation hit and have a serious technical and business impact.

Proof of Concept

https://github.com/code-423n4/2021-06-realitycards#mortar_board-governance-mortar_board

https://github.com/code-423n4/2021-06-realitycards/blob/86a816abb058cc0ed9b6f5c4a8ad146f22b8034c/contracts/RCFactory.sol#L444-L449

https://github.com/code-423n4/2021-06-realitycards/blob/86a816abb058cc0ed9b6f5c4a8ad146f22b8034c/contracts/RCOrderbook.sol#L117-L121

https://github.com/code-423n4/2021-06-realitycards/blob/86a816abb058cc0ed9b6f5c4a8ad146f22b8034c/contracts/RCTreasury.sol#L264-L268

Tools Used

Manual Analysis

Recommended Mitigation Steps

Change the single-step change of uberOwner address to a two-step process where the current uberOwner first approves a new address as a pendingUberOwner. That pendingUberOwner has to then claim the ownership in a separate transaction which cannot be done if they do not have the correct private key. An incorrectly set pendingUberOwner can be reset by changing it again to the correct one who can then successfully claim it in the second step.

@code423n4 code423n4 added 3 (High Risk) bug Something isn't working labels Jun 16, 2021
code423n4 added a commit that referenced this issue Jun 16, 2021
@Splidge Splidge added the duplicate This issue or pull request already exists label Jun 17, 2021
@Splidge
Copy link
Collaborator

Splidge commented Jun 17, 2021

Duplicate of #5

@Splidge Splidge marked this as a duplicate of #5 Jun 17, 2021
@Splidge Splidge closed this as completed Jun 17, 2021
@dmvt
Copy link
Collaborator

dmvt commented Jul 9, 2021

There is a very low probability coupled with a very high impact, making this a Medium risk issue in my opinion.

@dmvt dmvt reopened this Jul 9, 2021
@dmvt dmvt removed the duplicate This issue or pull request already exists label Jul 11, 2021
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
Projects
None yet
Development

No branches or pull requests

3 participants