Security Checkpoints for EIP-4337 Based Account Abstraction Implementation
Fairyproof conducts a study of EIP-4337 and present findings with security checkpoints.
EIP-4337 [1] is a proposal for implementing account abstraction which allows users to use smart contract wallets instead of an Externally Owned Account (EOA) as their primary account.
The biggest motivation to create this EIP is to avoid changes in Ethereum’s consensus layer and implement account abstraction mainly in smart contracts.
A significant feature that an account abstraction solution should have is to simulate transactions that users initiate with EOAs. The biggest difference between a transaction initiated by an EOA and one initiated by a contract account is that an EOA requires a signature signed by the EOA’s private key.
To implement such a solution, five concepts are introduced in this proposal: “UserOperation”, “Bundler”, “EntryPoint”, “Paymaster” and “Aggregator”.
A “UserOperation” is a data structure that defines a transaction initiated from an EOA. In this EIP it should be implemented and sent to a separate mempool.
A “Bundler” is a block builder that collects UserOperations from the mempool, or a user that can send transactions to a block builder. After a Bundler collects UserOperations, it will send them to a special contract defined as an “EntryPoint”.
An “EntryPoint” is a smart contract that validates and execute UserOperations sent by Bundlers.
A “Paymaster” is a smart contract that can help pay transaction fees on a users’ behalf. This feature is optional and can be used to allow users to pay fees with EIP-20 tokens.
An “Aggregator” is a helper contract. This feature is also optional and is used to validate aggregated signatures.
In essence, the logic proposed in this EIP are as follows:
As a blockchain security company, Fairyproof has studied this EIP and hoped to find all the security checkpoints that should be kept in mind when auditing a solution implemented based on this EIP.
We have studied these five concepts and their proposed implementation details. Here are our findings with security checkpoints:
1. Security Checkpoints for UserOperation’s Implementation
A significant security issue in the EIP’s proposed logic is that malicious actors could launch DOS attacks by sending invalid UserOperations to trick the EntryPoint into execute these operations without paying any fees.
Therefore, validating UserOperations in all the interfaces cannot be ignored.
The following sanity checks should be done for UserOperation:
- Either the sender is an existing contract, or the initCode is not empty (but not both)
- If initCode is not empty, parse its first 20 bytes as a factory address and check if the factory is staked. If the factory accesses global state, it must be staked.
- The verificationGasLimit should be sufficiently low (<= MAX_VERIFICATION_GAS) and the preVerificationGas should be sufficiently high (enough to pay for the calldata gas cost of serializing the UserOperation plus PRE_VERIFICATION_OVERHEAD_GAS)
- The paymasterAndData is either empty, or start with the paymaster address which is a contract that (i) currently has nonempty code on chain, (ii) has a sufficient deposit to pay for the UserOperation, and (iii) is not currently banned.
- The callgas is at least the cost of a CALL with non-zero value.
- The maxFeePerGas and maxPriorityFeePerGas should be above a configurable minimum value that the client is willing to accept. At the minimum, they are sufficiently high to be included with the current block.basefee.
- Only one UserOperation per sender may be included in a single batch. A sender is exempt from this rule and may have multiple UserOperations in the pool and in a batch if it is staked.
2. Security Checkpoints for EntryPoint’s Implementation
The “UserOperation” parameter in the handlOps and simulateValidation interfaces should be checked.
Particularly in the UserOperation data structure: the “sender” field should be a smart contract address rather than an EOA address, the “nonce” value should be unique to prevent replay attacks, the “initCode” should not be null if the account is not on-chain and needs to be created, the “signature” should be dependent on the chainid and the EntryPoint address to prevent replay attacks.
The “beneficiary” parameter in the handleOps and handleAggregatedOps should be a valid beneficiary address.
The EIP suggests the EntryPoint contract to be upgradable. The address that has access control to upgrade the contract should be managed with care and caution. In case it is compromised, the EntryPoint will be exposed to huge risks.
3. Security Checkpoints for IAggregatedAccount’s Implementation
The “userOp” parameter in the validateUserOp interface should be checked. The aforementioned points for “UserOperation” apply to this as well.
The “aggregator” parameter should be a valid address if an aggregator is used or can be ignored if no aggregators are used. And it should be the same as the return value of the “getAggregator” interface.
The “userOpHash” parameter should be a non-null value and be a hash over the userOp (except signature), EntryPoint and chainId.
Regarding the implementation of the validateUserOp interface, the following things should be checked:
- if its caller is a trusted EntryPoint and a smart contract address.
- If the account does not support signature aggregation, it must check if the signature is a valid hash of the userOpHash, and should return SIG_VALIDATION_FAILED (and not revert) if the signature doesn’t match. If any other error occurs, the transaction should be reverted.
- it must pay its caller (EntryPoint) at least the “missingAccountFunds” and may need to pay more to cover future transactions
The validateUserOp interface’s return value should be checked and corresponding operations should be performed according to the return value.
4. Security Checkpoints for IAggregator’s Implementation
The “userOp” parameter in the validateUserOpSignature, aggregateSignatures and validateSignatures interfaces should be checked. The aforementioned points for “UserOperation” apply to this as well.
The “signature” parameter in the validateSignatures should be a non-null value.
With regards to the Aggregator’s implementation, the following things should be specifically checked:
- validateSignatures() must validate the aggregated signature matches for all UserOperations in the array, and revert otherwise.
- An aggregator should stake to be trusted unless otherwise being exempt.
5. Security Checkpoints for Paymaster’s Implementation
The “userOp” parameter in the validatePaymasterUserOp interface should be checked. The aforementioned points for “UserOperation” apply to this as well.
The “userOpHash” parameter should be a non-null value and be a hash over the userOp (except signature), EntryPoint and chainId.
The “withdrawAddress” parameter in the withdrawStake and withdrawTo interfaces should be a valid address.
The “account” in the balanceOf and depositTo interfaces should be a non-zero valid address.
The “withdrawAmount” in the withdrawTo interface shouldn’t be greater than the return value of the balanceOf interface.
A Paymaster should be a valid smart contract address if it is introduced.
A Paymaster should have enough crypto assets to pay relevant operations if it is introduced.
A Paymaster should stake to be trusted.
Conclusion
These security checkpoints do not cover all the potential security issues that this EIP may introduce when implementing a solution. They are only what Fairyproof is specifically aware of when auditing such a solution.
Apart from these checkpoints, there are other important issues that have been extensively talked about in this EIP. These issues are mostly related to logical issues and should be seriously taken into consideration as well when auditing.
Reference:
[1] EIP-4337: Account Abstraction Using Alt Mempool, https://eips.ethereum.org/EIPS/eip-4337
Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Kristof Gazso (@kristofgazso), Namra Patel (@namrapatel), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Tjaden Hess (@tjade273), “ERC-4337: Account Abstraction Using Alt Mempool [DRAFT],” Ethereum Improvement Proposals, no. 4337, September 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4337.
New to trading? Try crypto trading bots or copy trading on best crypto exchanges
