Understanding ERC-4337 User Operation Packing Vulnerability

Understanding ERC-4337 User Operation Packing Vulnerability

Understanding ERC-4337 User Operation Packing Vulnerability

Understanding ERC-4337 User Operation Packing Vulnerability

Understanding ERC-4337 User Operation Packing Vulnerability

Read Time: 5 minutes

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.

  1. 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.
  1. The wallets can be altered and designed to intentionally avoid indexing by setting all the user operation hashes to be the same.
  1. 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.

  1. 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. 
  1. 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.
  1. 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.

4,038 Views

Blockchain for dog nose wrinkles' Ponzi makes off ~$127M🐶

Project promised up to 150% returns on investment in 100 days, raising about 166.4 billion South Korean won — or about $127 million — from 22,000 people.

Latest blogs for this week

Understanding Fuzzing and Fuzz Testing: A Vital Tool in Web3 Security

Read Time: 5 minutes When it comes to smart contracts, ensuring the robustness and security of code is paramount. Many techniques are employed to safeguard these contracts against vulnerabilities
Read More

How EigenLayer’s Restaking Enhances Security and Rewards in DeFi

Read Time: 7 minutes Decentralized finance (DeFi) relies on Ethereum staking to secure the blockchain and maintain consensus. Restaking allows liquid staking tokens to be staked with validators in
Read More

ERC 404 Standard: Everything You Need to Know

Read Time: 7 minutes Introduction Ethereum has significantly shaped the crypto world with its introduction of smart contracts and decentralized applications (DApps). This has led to innovative developments in
Read More

DNS Attacks:  Cascading Effects and Mitigation Strategies

Read Time: 8 minutes Introduction DNS security is vital for a safe online space. DNS translates domain names to IP addresses, crucial for internet functionality. DNS ensures unique name-value
Read More

EIP-4844 Explained: The Key to Ethereum’s Scalability with Protodanksharding

Read Time: 7 minutes Introduction  Ethereum, the driving force behind dApps, has struggled with scalability. High fees and slow processing have limited its potential. They have kept it from
Read More

QuillAudits Powers Supermoon at ETH Denver!

Read Time: 4 minutes Calling all the brightest minds and leaders in the crypto world! Are you ready to build, connect, and innovate at the hottest event during ETH
Read More

Decoding the Role of Artificial Intelligence in Metaverse and Web3

Read Time: 7 minutes Introduction  Experts predict a transformative shift in global software, driven by AI and ML, marking the dawn of a new era. PwC predicts AI will
Read More

Transforming Assets: Unlocking Real-World Asset Tokenization

Read Time: 7 minutes In the blockchain, real-world assets (RWAs) are digital tokens that stand for tangible and conventional financial assets, including money, raw materials, stocks, and bonds. As
Read More
Scroll to Top

Become a Quiffiliate!
Join our mission to safeguard web3

Sounds Interesting, Right? All you have to do is:

1

Refer QuillAudits to Web3 projects for audits.

2

Earn rewards as we conclude the audits.

3

Thereby help us Secure web3 ecosystem.

Total Rewards Shared Out: $200K+