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 OWNERSHIP TRANSFER #271

Closed
code423n4 opened this issue May 14, 2022 · 2 comments
Closed

SINGLE-STEP OWNERSHIP TRANSFER #271

code423n4 opened this issue May 14, 2022 · 2 comments
Labels
bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) duplicate This issue or pull request already exists QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-05-cally/blob/1849f9ee12434038aa80753266ce6a2f2b082c59/contracts/src/Cally.sol#L124
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/57725120581e27ec469e1c7e497a4008aafff818/contracts/access/Ownable.sol#L62

Vulnerability details

SINGLE-STEP OWNERSHIP TRANSFER

The current ownership transfer process involves the current owner calling transferOwnership(), from the OpenZeppelin Ownable contract. This function checks the new owner is not the zero address and proceeds to write the new owner’s address into the owner state variable. If the current owner writes the wrong address (e.g a typo) and the nominated EOA account is not a valid account, the functions with the onlyOwner modifier will not be able to be called anymore. In particular the function withdrawProtocolFees(), meaning all the protocol fees will be locked forever in the contract.

Impact

Medium

Proof Of Concept

Cally:124: function withdrawProtocolFees() external onlyOwner returns (uint256 amount)

Tools Used

Manual Analysis

Recommended Mitigation Steps

Consider implementing a two step process where the owner nominates an account and the nominated account needs to call an acceptOwnership() function for the transfer of ownership to fully succeed. This ensures the nominated EOA account is a valid and active account.

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels May 14, 2022
code423n4 added a commit that referenced this issue May 14, 2022
@outdoteth outdoteth added sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) labels May 15, 2022
@outdoteth
Copy link
Collaborator

outdoteth commented May 16, 2022

This requires the owner to actively make a mistake when upgrading to a new owner which is very unlikely since it will like only happen at most once every few months via multisig.

@outdoteth outdoteth reopened this May 16, 2022
@outdoteth outdoteth added sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons and removed sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") labels May 16, 2022
@HardlyDifficult
Copy link
Collaborator

Lowing to 1 (Low) and grouping with the warden's QA report #268

@HardlyDifficult HardlyDifficult added duplicate This issue or pull request already exists QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels May 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) duplicate This issue or pull request already exists QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons
Projects
None yet
Development

No branches or pull requests

3 participants