Interop: pdf might or might not render in a sandboxed iframe (depending on a browser)

[anforowicz]

Iframe sandbox disables plugins. This leads to the following interop problem: some browsers (like Chrome) implement PDF rendering via a plugin and therefore PDF might not render in a sandboxed iframe (or in pop-ups opened from a sandboxed iframe).

Brainstorming some ideas for how the spec can help interoperability here:

• Maybe the spec can introduce a mechanism for more granular sandboxing of plugins (e.g. so that a parent frame may allow its subframe to embed plugins handling application/pdf but not application/x-shockwave-flash). This doesn't seem to help interop, because for backcompatibility, the default behavior would have to block all plugins (and so the default behavior would remain not interoperable)

• Maybe the spec can give browsers some leeway in what plugins are blocked. For example - Chrome's PDF rendering restricts which APIs are exposed to PDFs (e.g. Net.* methods are not implemented) and maybe such restriction means that sandboxed frames should be allowed to embed PDF plugin.

• In the long term high-profile plugins like Flash and PNaCl will be deprecated (Flash by 2020 although AFAIK PNaCl remains supported for Chrome Apps for foreseeable future). Maybe this means that browsers shouldn't render PDF via a plugin?

Other notes:

• This is a follow-up to https://crbug.com/866292

[anforowicz]

FYI: @domenic, @tsepez

[domenic]

/cc @bzbarsky and @travisleithead as people who I remember being interested in issues around PDFs as a very special type of "plugin" (sometimes not a plugin). And @rniwa for good measure.

Vaguely related: #3462

[annevk]

https://html.spec.whatwg.org/#sandboxed-plugins-browsing-context-flag already allows for exceptions for secured plugins, which it seems like application/pdf might be in Chrome?

[mikewest]

I agree with @annevk that this isn't a spec issue; the spec clearly allows user agents to carve out plugins that act equivalently to web content with regard to sandboxing flags. I'm fairly certain that Chrome's PDF plugin does not respect things like allow-scripts and allow-top-navigation (but it's hard to test, given that it doesn't load at all at the moment :) ).

If we can secure it in this way, great! If not, then it seems correct to continue blocking it.

[annevk]

I think my preference at this point would be that we standardize upon not allowing sandboxed PDF and also start acknowledging PDF as a special type we'll have to account for going forward in page load.

[annevk]

Note that we have a test for this as well apparently: html/semantics/embedded-content/the-iframe-element/sandbox_004-manual.htm. (I think we could automate that with reftests and possibly fallback for the object element involved.)

[kelunik]

What's the recommended way to deliver untrusted PDFs if sandboxing isn't one of them?

[domenic]

I think the recommendation is: don't, since browsers are not capable of defending against malicious PDFs right now.

("Malicious" here = wants to do things disallowed by sandboxing, like navigate the parent page. Browsers can and do try to defend against PDFs that try to do system exploits like arbitrary code execution, as part of their same general code that defends against that for any content.)

[kelunik]

Given the protections against arbitrary code execution, I have more faith in browsers handling malicious PDFs than I have in users downloading and opening such files in their average PDF viewer app.

While browsers might currently not support the entire sandboxing set for PDFs, even a subset of the protections would be great, no?

[domenic]

I agree it would be great! Nobody has implemented it though.

[anforowicz]

What's the recommended way to deliver untrusted PDFs if sandboxing isn't one of them?

You can consider delivering untrustworthy PDFs from a separate origin or site (e.g. from https://untrustworthy-pdfs.example.com rather than from https://main-site.example.com). This should at least theoretically allow browsers to host such PDFs in a separate process (i.e. introducing a security barrier from the main site).

I recognize that unlike sandboxed iframes this approach doesn't put each PDF in a separate origin. In particular it still allows mixing of PDFs from various sources (e.g. PDFs provided by two different site users).

/CC @kmoon-chromium and @csreis as FYI