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

validatePaymasterUserOp allows for signature malleability #408

Closed
code423n4 opened this issue Jan 9, 2023 · 3 comments
Closed

validatePaymasterUserOp allows for signature malleability #408

code423n4 opened this issue Jan 9, 2023 · 3 comments
Labels
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 duplicate-453 edited-by-warden sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") unsatisfactory does not satisfy C4 submission criteria; not eligible for awards

Comments

@code423n4
Copy link
Contributor

code423n4 commented Jan 9, 2023

Lines of code

https://github.com/code-423n4/2023-01-biconomy/blob/main/scw-contracts/contracts/smart-contract-wallet/paymasters/verifying/singleton/VerifyingSingletonPaymaster.sol#L107

Vulnerability details

Impact

The validatePaymasterUserOp allows for both 64 and 65 sig lengths:

require(sigLength == 64 || sigLength == 65, "VerifyingPaymaster: invalid signature length in paymasterAndData");

This might result in signature malleability depending on which ECDSA version is used.

Proof of Concept

As already above described, the validatePaymasterUserOp function lays the first step for potential signature malleability due to it accepting a length of 64 as well. Depending on the used version of ECDSA.sol this will result in a potential vulnerability. We are aware that the deployment will most probably automatically use the fixed ECDSA.sol contract, however, if this codebase is ever forked with an older ECDSA.sol version, the vulnerability will occur, while this could be easily fixed. Hence the medium risk rating.

Tools Used

VSCode

Recommended Mitigation Steps

Consider limiting the sigLength acceptance to 65 in order to prevent potential signature malleabilities.

@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 Jan 9, 2023
code423n4 added a commit that referenced this issue Jan 9, 2023
@c4-judge
Copy link
Contributor

gzeon-c4 marked the issue as duplicate of #453

@c4-sponsor
Copy link

livingrockrises marked the issue as sponsor confirmed

@c4-sponsor c4-sponsor added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Feb 9, 2023
@c4-judge c4-judge added the unsatisfactory does not satisfy C4 submission criteria; not eligible for awards label Feb 10, 2023
@c4-judge
Copy link
Contributor

gzeon-c4 marked the issue as unsatisfactory:
Invalid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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 duplicate-453 edited-by-warden sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") unsatisfactory does not satisfy C4 submission criteria; not eligible for awards
Projects
None yet
Development

No branches or pull requests

3 participants