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

Lack of zero address check for ecrecover allows to bypass the signature verification #390

Closed
code423n4 opened this issue Oct 25, 2022 · 2 comments
Labels
bug Something isn't working 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

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-10-holograph/blob/main/contracts/HolographFactory.sol#L192-L264

Vulnerability details

Lack of zero address check for ecrecover allows to bypass the signature verification

  • In HolographFactory.sol there is a function which allows to deploy holographable smart-contract by providing DeploymentConfig, signature, signer. However, it's possible to bypass the require statement which verifies the signer by passing address(0) as a signer arg and some invalid signature with v being not equal to 27 or 28. As a result ecrecover() will return address(0) for invalid signature.

Proof of Concept:

  • The current tx: 0xcb1e58f6db0321b61869ea38f03d246c3809725b00be201cc0299fcd9a1dd57f on Goerli test network will disclose the scenario above.

  • Also, I've simulated exact transaction using tenderly in order to debug and see state changes much closer. Click to see

  • I'll attach a simple test case that helps to cover discovered scenario.

          it('should bypass the signature verification if signer is address(0)', async () => {
            signature.r = 0x${'00'.repeat(32)};
            let zeroAddress = '0x0000000000000000000000000000000000000000';
            await expect(
              l1.holographFactory.connect(deployer).deployHolographableContract(erc20Config, signature, zeroAddress)
            ).to.emit(l1.holographFactory, "BridgeableContractDeployed")
          });
  • After having a disscussion with @acc01ade(dev team), i figured out that the following exploit might have major impact on Holograph protocol.

Mitigation Steps:

  • Add an additional check against the signer being address(0).
    require(_verifySigner(signature.r, signature.s, signature.v, hash, signer) && signer != address(0), "HOLOGRAPH: invalid signature");
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Oct 25, 2022
code423n4 added a commit that referenced this issue Oct 25, 2022
@gzeoneth
Copy link
Member

Duplicate of #357

@gzeoneth gzeoneth marked this as a duplicate of #357 Oct 30, 2022
@gzeoneth gzeoneth added the duplicate This issue or pull request already exists label Oct 30, 2022
@gzeoneth gzeoneth added QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Nov 21, 2022
@gzeoneth
Copy link
Member

Consider with #501

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working 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
Projects
None yet
Development

No branches or pull requests

2 participants