{"id":217,"date":"2021-04-27T03:50:08","date_gmt":"2021-04-27T10:50:08","guid":{"rendered":"https:\/\/blog.mozilla.org\/attack-and-defense\/?p=217"},"modified":"2021-10-13T10:19:38","modified_gmt":"2021-10-13T17:19:38","slug":"examining-javascript-inter-process-communication-in-firefox","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/attack-and-defense\/2021\/04\/27\/examining-javascript-inter-process-communication-in-firefox\/","title":{"rendered":"Examining JavaScript Inter-Process Communication in Firefox"},"content":{"rendered":"

 <\/span><\/p>\n

Firefox uses Inter-Process Communication (IPC) to implement privilege separation, which makes it an important cornerstone in our security architecture. A previous blog post focused on fuzzing the C++ side of IPC<\/a>. This blog post will look at IPC in JavaScript, which is used in various parts of the user interface. First, we will briefly revisit the multi-process architecture and upcoming changes for Project Fission<\/a>, Firefox\u2019 implementation for Site Isolation. We will then move on to examine two different JavaScript patterns for IPC and explain how to invoke them. Using Firefox\u2019s Developer Tools (DevTools), we will be able to debug the browser itself.<\/p>\n

Once equipped with this knowledge, we will revisit a sandbox escape bug that was used in a 0day attack against Coinbase in 2019<\/a> and reported as\u00a0CVE-2019-11708<\/a>. This 0day-bug has found extensive coverage in blog posts<\/a> and publicly available exploits<\/a>. We believe the bug provides a great case study and the underlying techniques will help identify similar issues. Eventually, by finding more sandbox escapes you can help secure hundreds of millions of Firefox users as part of the\u00a0Firefox Bug Bounty Program<\/a>.<\/p>\n

Multi-Process Architecture Now and Then<\/b><\/h2>\n

As of April 2021, Firefox uses one privileged process to launch other process types and coordinate activities. These types are web content processes, semi-privileged web content processes (for special websites like accounts.firefox.com or addons.mozilla.org) and four kinds of utility processes for web extensions, GPU operations, networking or media decoding. Here, we will focus on the communication between the main process (also called “parent”) and a multitude of web processes (or “content” processes).<\/p>\n

Firefox is shifting towards a new security architecture to achieve Site Isolation, which moves from a \u201cprocess per tab\u201d to a \u201cprocess per site<\/a>\u201d architecture.<\/p>\n

\"Left:

Left: Current Firefox generally grouping a tab in its own process. Right: Fission-enabled Firefox, separating each site in its own process<\/p><\/div>\n

The parent process acts as a broker and trusted user interface host. Some features, like our settings page at about:preferences are essentially web pages (using HTML and JavaScript) that are hosted in the parent process. Additionally, various control features like modal dialogs, form auto-fill or native user interface pieces (e.g., the <select><\/code> element) are also implemented in the parent process. This level of privilege separation also requires receiving messages from content processes.<\/p>\n

Let’s look at JSActors and MessageManager, the two most common patterns for using inter-process communication (IPC) from JavaScript:<\/p>\n

JSActors<\/b><\/h3>\n

Using a\u00a0JSActor<\/a> is the preferred method for JS code to communicate between processes. JSActors always come in pairs – with one implementation living in the child process and the counterpart in the parent. There is a separate parent instance for every pair in order to closely and consistently associate a message with either a specific content window (JSWindowActors), or child process (JSProcessActors).<\/p>\n

Since all JSActors are lazy-loaded we suggest to exercise the implemented functionality at least once, to ensure they are all present and allow for a smooth test and debug experience.<\/p>\n

\"Inter-Process

Inter-Process Communication building on top of JSActors and implemented as FooParent and FooChild<\/p><\/div>\n

The example diagram above shows a pair of JSActors called FooParent<\/i> and FooChild<\/i>. Messages sent by invoking FooChild<\/i> will only be received by a FooParent<\/i>. The child instance can send a one-off<\/i> message with sendAsyncMesage(\"someMessage\", value)<\/code>. If it needs a response (wrapped in a Promise<\/code>), it can send a query with sendQuery(\"someMessage\", value)<\/code>.<\/p>\n

The parent instance must implement a receiveMessage(msg)<\/code> function to handle all incoming messages. Note that the messages are namespace-tied between a specific actor, so a FooChild<\/i> could send a message called Bar:DoThing<\/i> but will never be able to reach a BarParent<\/i>. Here is some example code (permalink, revision from March 25th<\/a>) which illustrates how a message is handled in the parent process.<\/p>\n

\"Code

Code sample for a receiveMessage<\/code> function in a JSActor<\/p><\/div>\n

As illustrated, the PromptParent<\/i> has a receiveMessage<\/code> handler (line 127) and is passing the message data to additional functions that will decide where and how to open a prompt from the parent process. Message handlers like this and its callees are a source of untrusted data flowing into the parent process and provide logical entry points for in-depth audits<\/p>\n

Message Managers<\/b><\/h3>\n

Prior to the architecture change in Project Fission, most parent-child IPC occurred through the MessageManagers system. There were multiple message managers, including the per-process message manager and the content frame message manager, which was loaded per-tab.<\/p>\n

Under this system, JS in both processes would register message listeners using the addMessageListener<\/code> methods and would send messages with sendAsyncMessage<\/code>, that have a name and the actual content. To help track messages throughout the code-base their names are usually prefixed with the components they are used in (e.g., SessionStore:restoreHistoryComplete<\/code>).<\/p>\n

Unlike JSActors, Message Managers need verbose initialization with addMessageListener and are not tied together. This means that messages are available for all classes that listen on the same message name and can be spread out through the code base.<\/p>\n

\"Inter-Process

Inter-Process Communication using MessageManager<\/p><\/div>\n

As of late April 2021, our AddonsManager – the code that handles the installation of WebExtensions into Firefox – is using MessageManager APIs:<\/p>\n

\"Code

Code sample for a receiveMessage<\/code> function using the MessageManger API<\/p><\/div>\n

The code (permalink to exact revision<\/a>) for setting a MessageManager looks very similar to the setup of a JSActor with the difference that messaging can be used synchronously, as indicated by the sendSyncMessage call in the child process<\/a>. Except for the lack of lazy-loading, you can assume the same security considerations: Just like with JSActors above, the receiveMessage<\/code> function is where the untrusted information flows from the child into the parent process and should therefore be the focus of additional scrutiny.<\/p>\n

Finally, if you want to inspect MessageManager<\/code> traffic live, you can use our logging framework<\/a> and run Firefox with the environment variable MOZ_LOG<\/code> set to MessageManager:5<\/code>. This will log the received messages for all processes to the shell and give you a better understanding of what\u2019s being sent and when.<\/p>\n

Inspecting, Debugging, and Simulating JavaScript IPC<\/b><\/h2>\n

Naturally, source auditing a receiveMessage<\/code> handler is best paired with testing. So let’s discuss how we invoke these functions in the child process and attach a JavaScript debugger to the parent process. This allows us to simulate a scenario where we have already full control over the child process. For this, we recommend you download and test against\u00a0Firefox Nightly<\/a> to ensure you’re testing the latest code – it will also give you the benefit of being in sync with codesearch for the latest revisions at\u00a0https:\/\/searchfox.org<\/a>. For best experience, we recommend you download Firefox Nightly<\/a> right now and follow this part of the blog post step by step.<\/p>\n

DevTools Setup – Parent Process<\/b><\/p>\n

First, set up your Firefox Nightly to enable browser debugging. Note that the instructions for how to enable browser debugging can change over time, so it’s best you cross-check with the instructions for Debugging the browser on MDN<\/a>.<\/p>\n

Open the Developer Tools, click the “\u00b7\u00b7\u00b7<\/b>” button in the top-right and find the settings. Within Advanced settings<\/i> in the bottom-right, check the following:<\/p>\n