Issue 413851 in chromium: Sandbox breaks PDF rendering

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Pri-2 Via-Wizard Type-Compat OS-Mac

New issue 413851 by dev.akh...@gmail.com: Sandbox breaks PDF rendering
https://code.google.com/p/chromium/issues/detail?id=413851

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36

Example URL:
http://htmlpad.org/csp-pdf-iframe-sandbox/

Steps to reproduce the problem:
Go to http://htmlpad.org/csp-pdf-iframe-sandbox/

What is the expected behavior?
Pdf renders in frame

What went wrong?
PDf doesn't render. Removing sandbox attribute allows rendering.

Does it occur on multiple sites: No

Is it a problem with a plugin? Yes PDF Reader

Did this work before? N/A

Does this work in other browsers? Yes

Chrome version: 37.0.2062.120 Channel: stable
OS Version: OS X 10.9.4
Flash Version: Shockwave Flash 15.0 r0

This is because Chrome creates a HTML document with a plugin inside, and
then the sandbox blocks the plugin. But the creation of the HTML document
is a Chrome internal implementation detail and abstractly, the developer is
only pointing an iframe to the PDf.

A similar problem also exists for the CSP sandbox directive. This is
annoying since it would be nice to send PDFs without any privileges (or in
general, sandbox all static content so that any content-sniffing issues
can't cause code execution)

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Status: Untriaged
Labels: OS-All

Comment #1 on issue 413851 by song...@chromium.org: Sandbox breaks PDF
rendering
https://code.google.com/p/chromium/issues/detail?id=413851

Reproducible in Chrome 39.0.2152.0 / Win7, Ubuntu12.04, Mac OSX 10.9.4

[chro...@googlecode.com]

Updates:
Cc: tse...@chromium.org
Labels: -OS-Mac Cr-Internals-Plugins-PDF Cr-Security Cr-Internals-Plugins

Comment #3 on issue 413851 by mk...@chromium.org: Sandbox breaks PDF
rendering
https://code.google.com/p/chromium/issues/detail?id=413851

PDF is a plugin, and plugins are denied inside sandboxed IFrames. The fact
that an HTML document is created is somewhat irrelevant; the frame is
sandboxed, which governs the things that can be instantiated inside it.

There's an open question as to whether we could allow sandboxed plugins
(like the PDF renderer, or pepper Flash) inside sandboxed documents. I
think Tom was looking into this at some point (+tsepez).

[chro...@googlecode.com]

Updates:
Cc: mk...@chromium.org

Comment #4 on issue 413851 by mk...@chromium.org: Sandbox breaks PDF
rendering
https://code.google.com/p/chromium/issues/detail?id=413851

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #5 on issue 413851 by dev.akh...@gmail.com: Sandbox breaks PDF
rendering
https://code.google.com/p/chromium/issues/detail?id=413851

The demo has an iframe because that is the easier demo link to create.

But actually, I am much more interested in this issue in context of CSP. It
seems like a reasonable thing for a website to mark off all its static
resources as sandboxed so that any HTML there (present or sniffed) could
not have an XSS that completely pwns the main website. But, in the current
CSP sandbox implementation, setting a sandbox header on the PDF file forces
it to not render at all. This seems sub-optimal: surely, we want to
encourage broader use of sandbox and enabling sandboxing easily is one way
to do that.

Knowing the similarities between sandbox and sub-origins, I won't be
surprised if a similar issue will come up when sub-origins are implemented.

The comparison I think I would draw is that of an image: if I add a sandbox
header to an image, it shouldn't mean that Chrome does not render it as an
image. What it should mean is that if it is content-sniffed as an HTML
file, that HTML file runs in a sandbox'ed origin.

[chro...@googlecode.com]

Comment #6 on issue 413851 by rue1...@gmail.com: Sandbox breaks PDF
rendering
https://code.google.com/p/chromium/issues/detail?id=413851

Rendering is even broken in new windows opened from an IFRAME with SANDBOX
attribute.

This means that the user can have tabs in his browser, that look like
normal tabs (ie have an address bar), can do nearly everything, but will
not show PDFs (even if "reused" by manually entering an URL). This could be
very confusing to the user.

[chro...@googlecode.com]

Comment #7 on issue 413851 by s...@onegiantmedia.com: Sandbox breaks PDF
rendering
https://code.google.com/p/chromium/issues/detail?id=413851

This is completely breaking our application for our clients that have Flash
inside the iframe. We want to allow everything explicitly
using "allow-same-origin allow-top-navigation allow-scripts allow-forms
allow-popups"

If you allow Flash plugin on the page and the user wants it and has it
enabled as a plugin, why would you block it when sandbox is allowing 100%
everything and yet allow it when there is no sandbox attribute at all,
which is supposed to mean full restriction?

This doesn't make sense and should be fixed. This is one of the few cases
where IE actually got something right that Chrome has backwards.