The world of Web3 is a world of protocols and standards. You sure must have come across several ERC standards. Some of the most famous ERC standards are 20 and 721, which are for tokens and NFT, respectively. But Web3 is not limited to that.
We see regular updates and upgrades in Web3. One of the latest upgrades was ERC 4337, deployed on Ethereum Mainnet in March 2023. Not every update is successful in one go; the same is true with ERC 4337. In this blog, we will learn about vulnerabilities regarding the User Operation section of the standard and their impact. Firstly let’s start with a brief introduction to ERC 4337 standard.
What is ERC 4337?
Unlike Bitcoin’s network, Ethereum supports smart contracts on the chain, which makes Ethereum have two different types of accounts, one transactional or an operational account. In addition to that, smart contracts have their own space, almost like an account. These two types of accounts in Ethereum have their own functionalities.
Most wallets functioning with Ethereum are EOA’s which means the user’s accounts, not the smart contract ones. These type of accounts have their own limitations. One limitation includes the sole reliance of the user on the private keys to access accounts and requiring all signatures for transactions. These limitations prompted the introduction of ERC 4337.
The ERC 4337 attempts to provide account abstraction by combining the best of the two account-type features. Yes, EOA’s and smart contract accounts. This is made possible by a single contract that can transact tokens and create contracts simultaneously, and ERC 4337 is a standard facilitating this awesome new advancement.
UserOperation packing vulnerability
Everything about this standard and project is awesome, but what went wrong? Well, there was an implementation issue which resulted in inconsistent hashes based on the method used to sign. This lead to order clashes, particularly divergent hashes for the same UserOperations and colliding hashes for different UserOperations.
The affected regions were confined to two vulnerabilities, the EntryPoint Packing Vulnerability and the VerifyingPaymaster Packing Vulnerability. More on that later. Let’s first have a general understanding, and then we will learn about them individually.
Let’s have a look at the UserOperation.sol:-
You see the UserOperation parameter, a Calldata, being passed as an argument to the pack function. Let’s explore the struct:-
These are the fields that the UserOperation struct carries. To copy this large portion of the Calldata into memory, the code segments use assembly. Some methods of the contracts intend to capture all fields of the UserOperation, including the variable-size fields, also called dynamic fields in ABI encoding. For example, the dynamic encoding in this struct is ‘initCode’, ‘callData’ and ‘paymasterAndData’.
Some methods cannot include ‘paymasterAndData’ because that field is not defined or declared yet. Methods use the ‘.offset’ convenience field provided to dynamic data types to do that. But the contracts that use ABI-encoded arguments do not validate the order in which the fields are defined and the offsets’ validity. It is possible to construct a valid representation of the user operations in Calldata with unusual hash properties.
EntryPoint Packing Vulnerability
The issue with the UserOperation affects some of the other parts of the standard as well, EntryPoint Packing vulnerability is one of those. When a different hashing scheme is used between the EntryPoint and wallet contract or a non-standard user operation encoding is used, we see hash divergence.
The risk surfaces as EntryPoint. Now a single user operation could be represented by multiple ‘user op hashes’, and the same ‘user op hash’ could represent multiple user operations. Now this can create some unwanted effects. Let’s discuss the impact it can have.
The Erc 4337 is still at a very early stage, as it was just released in March, so the impact of these vulnerabilities is not fully known. It is hard to describe the potential impact from a bird’s eye view. Over that, the impact depends on implementing bundlers, indexers, user operation explorers and other off-chain services. Let’s look at a few of the issues this vulnerability causes.
- This can cause a confusing experience for the user because the user operation hash can change between submission and inclusion time. This phenomenon is unknown to most wallets, so they might not account for that difference.
- The wallets can be altered and designed to intentionally avoid indexing by setting all the user operation hashes to be the same.
- We can see mishandling of data and keys if an off-chain service monitoring the user operation inclusion misses the inclusion of a given user operation.
VerifyingPaymaster Packing Vulnerability
Nobody likes ordering something from online shopping and receiving an entirely different product. The same is on Web3, but this vulnerability degrades the user experience. A user may have altered or different contents between the signing time and inclusion on the chain. And the reason why this happens is that two different user operations return the same hash from the ‘VerifyingPaymaster.getHash()’ function.
The VerifyingPaymaster.getHash() function takes a few arguments like ‘UserOperation’, which is a struct, ‘validUnitl’, a uint48 value and a validAfter another uint48 value. The issue of the different contents between signing time and inclusion time impacts the user experience and overall security. Let’s discuss a few of the concerns it raises.
- Offchain signers that sign in an ABI-encoded format after receiving user operations or signers with contract integrations to prepare data for signature become vulnerable.
- The hash can be modified to cover fewer elements than expected, which can lead to some of the static fields, like initCode etc., being excluded from the hash. This may result in a different use than intended for the paymaster sponsorship signatures.
- We can see a breach and bypass of the rules by changing the userOp.initCode and userOp.callData after getting a signature. This will allow the paymaster’s native token to be used for purposes other than minting gasless NFT.
Conclusion
With the ever-ongoing advancement and development, we will witness many awesome things, and ERC 4337 is one of them. While developing and advancing security is something that we can never compromise. It is awesome to note how quickly the vulnerabilities were found in the standard, and continuous research and development are being carried out to make it secure.
It is important to note that even some of the biggest and most well-known organisations building in Web3 can make security-related mistakes, and surely the other protocols make them too. The continuous rise in Web3 incidents in the last few years is evident.
The one-stop solution to protect you, your users, and your protocol from such security threats is going for an audit. We at QuillAudits, are one of the top service providers in smart contract auditing and blockchain security, Do visit our website to find out more and get your project secured. And stay tuned to enjoy more such informative blogs.
782 Views
