Adjusting flags per comment #0 and #1.

Even without out-of-process-iframes, isn't there's a way that an attacker to launch arbitrarily many child processes with a single user gesture: 

Open a second tab:
  // this step requires a user gesture
  w = window.open("http://cross-site-url", "_blank");
Then:
  // This will launch a new renderer the tab if it's currently crashed:
  w.location.href = "http://cross-site-url";
  // wait
  w.location.href = "http://cross-site-url";
  // wait
  w.location.href = "http://cross-site-url";

etc. This doesn't have all the same properties and fan-out potential as the oopif case, but if we want to rate limit process launch after crash, we should probably start by developing a heuristic that fixes this non-oopif case.

> I would like the number of renderer processes an attacker can crash to at least be limited to something vaguely resembling the number of user gestures the attacker receives.

We can contemplate some kind of rate-limit. Here are some questions:
 - For the sort of exploit we're hoping to defeat, what sort of probability of success is expected with each attempt, and how long does each attempt take?
 - Does a rate limit apply before the first crash occurs? Doing so seems to risk either breaking legitimate content (by stalling iframe loads for no apparent reason) or else providing a way to trivially defeat site isolation (if the effect of hitting the rate limit is to no longer transfer navigations out of unsuitable processes).
 - What action do we take once we hit the rate limit? Is it enough to bring down a tab, or do we need to bring down the whole BrowsingInstance?
 - Does a user reloading a tab reset the limit? Does a top-level navigation?
 - Should consideration of this ASLR-defeat scenario inform our approach to RenderProcessHost reuse and consolidation?  Currently (with --isolate-extensions) in the extension(a.com, b.com) case, siblings a and b are given separate processes, though this is not needed for security.
 - Do we assume our adversary is in control of an arbitrary number of random domains, or can we consider approaches where the rate limit is segmented by domain?
 - With just --isolate-extensions, is there a way for an attacker to create arbitrarily many non-extension oopif processes without controlling an extension?
 - Do we need a different strategy for --top-document-isolation versus full site isolation? In TDI mode a crash may naturally affect several tabs.

> Even without out-of-process-iframes, isn't there's a way that an attacker
> to launch arbitrarily many child processes with a single user gesture:

Oh, interesting. I didn't realize that you can already hold references to cross-process
renderers like this.

>  - For the sort of exploit we're hoping to defeat, what sort of probability
> of success is expected with each attempt, and how long does each attempt take?

This one is really hard to answer, partly because "crash until it works" is a relatively
universal concept that e.g. applies to address bruteforcing and to attacks that depend on heap
layout. I'll try asking some other Project Zero people for opinions - I don't have much
experience with attacks related to heap layout.


>  - What action do we take once we hit the rate limit? Is it enough to bring down a tab,
> or do we need to bring down the whole BrowsingInstance?

IMO bringing down the tab (and making sure that it stays dead) should be enough, based on
the assumption that tabs should be a scarce resource for an attacker.

>  - Does a user reloading a tab reset the limit? Does a top-level navigation?

Top-level navigations can be triggered by the website, so I think they shouldn't
reset the limit. If a user reloads the tab, IMO it would probably be fine to reset the
limit.

>  - Do we assume our adversary is in control of an arbitrary number of random domains, or
> can we consider approaches where the rate limit is segmented by domain?

At least if you respect the public suffix list here, creating an ~arbitrarily
large number of domains probably isn't too hard.

I talked to some other Project Zero people, and I think the conclusion was that attacks that require crashing and would trigger crash reports aren't very useful. So I think this can be closed.

For sake of completeness, it is worth noting that not all installs have crash reporting enabled, so there is subset of installs that will not be reporting.

As stated in chat, I'm also of the opinion that this is possible today already, so having out-of-process iframes doesn't create the problem, maybe makes it a bit easier.

mac triage: marking this WontFix per #5.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot