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

Direct usage of ecrecover allows signature malleability #385

Closed
Tracked by #88
code423n4 opened this issue Oct 25, 2022 · 5 comments
Closed
Tracked by #88

Direct usage of ecrecover allows signature malleability #385

code423n4 opened this issue Oct 25, 2022 · 5 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 responded The Holograph team has reviewed and responded sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Lines of code

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

Vulnerability details

Impact

The _verifySigner function of Holograph calls the Solidity ecrecover function directly to verify the given signatures.
However, the ecrecover EVM opcode allows malleable (non-unique) signatures and thus is susceptible to replay attacks.

If the expected address is also the zero address (address(0)), the signature verification will pass although the signature is invalid.

Ensuring the signatures are not malleable is considered a best practice (and so is checking signer != address(0), where address(0) means an invalid signature).

https://swcregistry.io/docs/SWC-117
https://swcregistry.io/docs/SWC-121

Proof of Concept

contracts/HolographFactory.sol:
  319     */
  320:   function _verifySigner(
  321:     bytes32 r,
  322:     bytes32 s,
  323:     uint8 v,
  324:     bytes32 hash,
  325:     address signer
  326:   ) private pure returns (bool) {
  327:     if (v < 27) {
  328:       v += 27;
  329:     }
  330:     /**
  331:      * @dev signature is checked against EIP-191 first, then directly, to support legacy wallets
  332:      */
  333:     return (ecrecover(keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash)), v, r, s) == signer ||
  334:       ecrecover(hash, v, r, s) == signer);
  335:   }

Tools Used

Manual Code Review

Recommended Mitigation Steps

Use the recover function from OpenZeppelin's ECDSA library for signature verification.

@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 Oct 25, 2022
code423n4 added a commit that referenced this issue Oct 25, 2022
@gzeoneth gzeoneth added disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) out of scope This finding falls outside the contest scope as delineated in the contest README labels Oct 30, 2022
@gzeoneth
Copy link
Member

./library is out-of-scope and no direct exploit

@alexanderattar
Copy link

We will add a check for zero address

@alexanderattar alexanderattar added sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") responded The Holograph team has reviewed and responded labels Nov 8, 2022
@gzeoneth
Copy link
Member

gzeoneth commented Nov 8, 2022

We will add a check for zero address

this is regarding malleability btw

@ACC01ADE ACC01ADE removed the out of scope This finding falls outside the contest scope as delineated in the contest README label Nov 18, 2022
@ACC01ADE
Copy link

This is in-scope since the referenced code is not in library but a direct function in HolographFactory. Agreeing that this is not regarding zero address but signature malleability (specifically s-values in the upper range).

@gzeoneth gzeoneth added 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 Nov 19, 2022
@gzeoneth gzeoneth added the duplicate This issue or pull request already exists label Nov 21, 2022
@gzeoneth
Copy link
Member

Consider with #397

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 responded The Holograph team has reviewed and responded sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

4 participants