Navigating the Security Landscape of MetaMask Snaps

MetaMask Snaps is an open-source system that enables users to safely extend MetaMask's functionality, offering new wallet experiences. At its core, Snap is a JavaScript program operating inside MetaMask in an isolated environment.

In this blog we’ll explore the MetaMask Snaps security landscape. As blockchain security auditors from Consensys Diligence, we specialize in smart contract security. Consensys Diligence is a blockchain security firm with a comprehensive smart contract audit service to help projects across web3 build safe dapps.

Understanding the MetaMask Snap trust model

Every Snaps developer needs to understand the trust model inherent to MetaMask Snaps. This trust model delineates the trust boundaries between the different actors. The key message to remember is that end-users trust MetaMask but do not trust the dapps.

We formalized and summarized the trust model in the diagram below. This diagram depicts the different trust boundaries that developers must keep in mind when developing Snaps:

Three main trust boundaries for web3 dapps, users, and MetaMask

First, there is a trust boundary between the user and the dapp. Users never trust dapps. Indeed, dapps can be malicious, or compromised. They can make users believe that they are signing a given payload when in fact, they are signing something else.

Second, there is a trust boundary around MetaMask and its extensions. Indeed, while users do not trust dapps, they trust MetaMask. MetaMask is the source of truth for the user. The payload displayed and signed inside MetaMask, whether it is through its core module, or Snaps, is what matters.

Third, there is also a trust boundary between the MetaMask core module and the Snap. Indeed, Snaps developers can interact with the core module of MetaMask through the Snaps API. This API implements a permission system meaning developers have to request permissions before accessing restricted API features. Yet, with appropriate permissions, Snaps can carry out critical actions such as accessing MetaMask root entropy, signing data, or communicating with external APIs.

In essence, the guiding principle for end-users in the MetaMask ecosystem is straightforward yet profound: End users should only have to trust in the information and interactions that occur within the MetaMask and MetaMask Snap context, known as the Trust Module.

Decoding common issues in MetaMask Snaps

The MetaMask trust model allows for a structured audit approach and helps auditors to identify security issues. During our Snaps audits, we identified different categories of issues. We were still curious about other potential categories. Thus, we conducted a comprehensive analysis across 40 Snaps audited by 9 audit firms. We created a classification and categorized the issues according to this classification. Below we highlight a few interesting categories along with some examples. Note that this list is not exhaustive.

User input validation:

1. Markdown & control character injection: This involves the risk of unwanted code or commands being injected through markdown or control characters in user inputs.
2. User input sanitization & validation:
   • Type-checking/type-confusion and parsing issues
   • API not rejecting invalid RPC parameters: This problem occurs when the API fails to reject invalid parameters such as incorrect chain IDs, address checksums, or fee structures.
   • Improper URI validation: This problem can occur when using lax regex expressions when validating URIs, for instance.

User consent & user interface issues:

1. Breaking MetaMask established UX pattern: This issue surfaces when applications deviate from the established user experience patterns of MetaMask.
   • Not prompting the user for account access: MetaMask always prompts the user before connecting any account to the dapp. Snaps developers should follow the same pattern.
   • Account enumeration: A privacy concern where the application might enumerate or list user accounts without proper consent.
2. Not asking for user consent:
   • When signing payloads: This refers to instances where the application performs signature-related actions without explicit user approval.
   • Displaying private key without password visibility toggle: private keys are displayed without using a click-to-reveal component accompanied with a disclaimer text. This can be problematic if the user is in a public environment for instance.
3. Opaque snap dialogs: These are dialogs that lack transparency or clarity.
   • Transaction signing dialog with missing information: A case where essential information is omitted in transaction signing dialogs, or the information presented to the user is not human-readable.
   • Fee rounding imprecision issues: This pertains to inaccuracies or lack of precision in fee calculations and displays.
   • Displaying the origin: The Snaps does not display the origin of an action. This can trick the user into thinking the action was initiated by a dapp when in fact it was from another dapp.

Dependency issues:

1. Vulnerable/untrusted dependencies.
2. Supply-chain attacks: A dependency can become compromised, either through direct or indirect attack vectors.
3. Outdated dependencies: Relying on outdated dependencies can have bad security implications, as these dependencies might contain vulnerabilities.

Permission and authorization issues:

1. Superfluous permissions: Granting too many permissions leads to decreased security.
2. Accessing low-level permissions: Improperly managing MetaMask root keys entropy for Ethereum for instance.
3. Leakage of cryptographic material:
   • Dapp requests for private key: Private keys must never leave MetaMask!
   • Account management: The snap should prompt the user before connecting any account upon the first connection.

We are currently refining the results of our analysis and identifying new insights. More is coming soon. Stay tuned :)

Key takeaways for Snap developers

Be aware that you are developing a trust module! users trust MetaMask, but not the dapp. The user must confirm every action and they should have all the information available to make an informed decision. Keys never leave MetaMask. Consequently, as a Snaps developer, you can:

1. Request minimal permissions: Snaps should only ask for access to the specific functionalities or data necessary for their operation to minimize the attack surface.
2. Validate and sanitize tainted inputs: Avoid injection attacks or execution of untrusted code. Given the Snap's ability to extend the functionality of a user's wallet, ensuring that all inputs are secure and free from exploits is vital for protecting both the wallet's integrity and the user's assets.
3. Manage supply chain: Carefully select and update dependencies to avoid vulnerabilities.

Having those principles and the underlying common issues in mind during development makes the future of Snaps a lot safer for the next billion.

Consensys Diligence has helped a wide range of projects across the blockchain ecosystem to ensure their protocols are ready for launch and built to protect users. Consensys Diligence is happy to check your Snap for these and more vulnerabilities in a custom audit. Hit us up and get a quote!

Martin Ortner (tintinweb)

Valentin Quelquejay

Martin and Valentin, Security professionals at Consensys Diligence, are at the forefront of Snap security research, diligently working to enhance the platform's security