Our blog is live! Read this article on our Safe Blog.

TL;DR:

A Medium threat issue was found with v0.1.0 of the 4337 Canonical Module for Safe. This module has not been used outside of testnets like Goerli and Mumbai. As a result, there has been no risk to user funds.

Related to the optional paymaster feature, this issue has since been addressed with an enhanced v0.2.0. The fully audited v0.2.0 are being deployed on Goerli, Polygon, Mumbai and Sepolia.

The Canonical 4337 Module for Safe released on 28 Nov 2023 provides an opt-in approach for Safes to add compatibility with the ERC-4337 tool stack. It allows developers to use ERC-4337 bundlers to execute transactions via the Safe and other features of the ERC-4337 stack, such as paymasters. The Canonical 4337 Module treats paymasters as an opt-in feature that can be added on-demand to cover gas costs for the user.

Paymasters allows you to delegate the gas fee payment to another contract instead of the user account. For this, it is possible to set the paymaster address and data that should be forwarded to the paymaster in the UserOperation. The entry point calculates the required ETH to execute the transaction based on the gas parameters provided in the User Operation. When a paymaster is set, the Entry point will not request the account to pay and instead forward the payment request to the paymaster.

The paymaster then can implement the logic to check if it accepts the payment requests or reverts if it does not cover the fees.

The Canonical 4337 Module treated the paymaster as an opt-in feature, where the dApp can decide afterward which and if to use the paymaster. The problem with this is that the fee request for the account and the paymaster are based on the same gas fee parameters. As the paymaster is not enforced, this makes it possible that no paymaster is set, and that the account would then have to pay for the gas fees. Even more of an issue is that this causes an indeterministic behaviour, as multiple UserOperations with different paymasters can exist in the mempool that are all valid.

The 4337 module computes its own “Safe operation” hash for signature verification when validating user operations. However, the ERC-4337 EntryPoint already computes a user operation hash and passes it to the account. This userOpHash encompasses all parameters of a user operation, allowing it to uniquely identify a user operation for an account, so why not use it directly?

Unfortunately, the 4337 userOpHash is not compatible with EIP-712. This means that, as a user, you would have to trust the dApp to correctly display all information of the user operation for a Safe owner to sign, as the entire user operation would be represented as a single opaque hash in your wallet. As an ecosystem, we moved away from signing opaque transaction hashes with eth_sign long ago, and with good reason. We want to ensure that all transactions from a Safe can be clear-signed, and this requires custom logic to compute a “Safe operation” hash in the contracts instead of reusing the userOpHash computed by the ERC-4337 EntryPoint.

As this allows malicious parties to adjust or remove the paymaster, this can cause unexpected behaviour for the user, where in the worst case, the user has to cover the gas fees without expecting it. This only impacts accounts that hold enough ETH to cover the fees. As the Canonical 4337 Module has not been used yet in production, no user funds have been at risk.

As we reflect on the recent challenges and the subsequent resolution of the vulnerability within the Canonical 4337 Module, several key learnings and conclusions have emerged:

The open-source nature of our projects has once again proven to be an invaluable asset in ensuring security. We extend our heartfelt gratitude to Taek, whose vigilance and expertise were instrumental in identifying this issue. This instance underscores the importance of community collaboration and early exposure to the ecosystem, which allows for a more diverse range of insights and quicker identification of potential vulnerabilities.

Adopting a modular approach in our development has significantly limited the risk associated with this vulnerability. We're pleased to confirm that no existing Safes were impacted, thanks to the isolated nature of this module. This incident highlights the advantages of modular design – it enables focused updates and improvements and ensures that the core functionalities remain secure and unaffected. Users can continue to rely on the default Safe execution flow for secure access to their funds, even as we enhance specific aspects of our system.

The ERC-4337 tech stack, a relatively new addition to our toolset, presents unique challenges and opportunities. This incident has highlighted the need for thorough documentation of how different stack features are utilised within our contracts. As we continue to explore and integrate cutting-edge technologies, a heightened focus on security becomes ever more crucial. Going forward, our team is dedicating additional resources and attention to ensure that every aspect of our tech stack is robust, secure, and aligns with our high standards.

This incident underscores our dedication to maintaining the highest security and transparency standards, stronger than ever. Armed with the insights gained from this experience, we are more determined to enhance our product development process, ensuring we consistently deliver secure, dependable, and cutting-edge solutions to our community.