[Back to top]

IPC Security Models and Status

Randell Jesup

Reviewers: pauljt, baku, bkelly, posidron, ehsan


Current State:

IPC security is basically ad-hoc, implemented by each IPC protocol implementation.

The basics are that many parts of our system are gatewayed by using Principals, which encode the origin and related information associated with the document. Largely we rely on good reviewers, and that’s more for avoiding sec issues like UAFs.

There are currently many components that send (child-to-parent) a Principal or a PrincipalInfo, but the parent is not really able to know if the child is allowed to use that principal. We should be able to validate what Principals a Content Process is allowed to use with data stored in the ClientManagerService. This is being worked on in bug 1432825 and bug 1432831, though that just covers a single case; resolving bug 1432831 would provide examples on how to do similar argument validation elsewhere.

As an example of Principal validation, when BroadcastChannel is sending a message, it sends the origin and its principal. The check is done on the parent side.

Once we have Site Isolation, the danger when Principle ownership isn’t checked is that if a compromised Content Process (somehow) knows a principal that’s valid in another document, it could pass it up, masquerading as that other document. Without checking if that document is loaded into that Content Process, the Master process will allow the action to proceed with an incorrect Principal. This can lead to all sorts of information leakage or spoofing. (Note: since a current Content Process could be navigating to a new origin, we can’t really stop a compromised Content Process from getting a Principal for a random origin until we have support for process-per-origin (or set of origins) and necessary process switching code for navigations).

The issue isn’t just Principals, however; all arguments must be checked, and where possible validated against what a given sender should be able to use.

In addition to information leakage, crafting arguments for an IPC message can also lead to considerable risk of sandbox escape - sending an IPC request with invalid arguments to trick the Master Process into taking an action that leads to the master process hitting a UAF or other security issue. Luckily, even in this case it’s hard to craft an escape, but this greatly increases the possibility.

Securing IPC code is important. It’s more critical as we move towards site isolation - compromise of a Content Process with 1/4 your tabs (and everywhere you browse in the future in those) is pretty bad, so a sandbox escape is only incrementally worse, but with site isolation a compromised process may be worth much less, unless it can escape.

Best Practices:

Possible Improvements to our IPC use:

Further Investigations

Prior work from Security Assurance Team on sandboxing (pauljt)


The key activities that we have done are:

IPDL auditing

We’ve been through IPDL in an ongoing manner, but most recently the approach we took was here. Summary:

External IPDL Audit

I also used some parental leave backfill to get a timeboxed audit of IPDL last year from a contractor (Stephen Fewer). It was only a month though, so very timeboxed.

Message manager audit

Other sandbox related auditing activities

Specific Protocols and IPC messages Audit (jesup)

We have (currently) about 144 separate non-test .ipdl files in the tree. Looking in them for “manager XXXXXX”: (This search may be comparable to mine below, but I don’t trust it as much - instances of manager in searchfox)

Looking at all the methods inside these ipdl files, there are roughly:

Examination of example protocols:

[Back to top]