

Same origin violation and local file stealing via PDF reader - ehPReth
https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/

======
JoshTriplett
Why does pdf.js even _have_ any special permissions? It doesn't need any to
render a PDF.

~~~
kevingadd
If I'm reading the disclosure right, the injection is into a non-privileged
part of the PDF reader. But the PDF reader is loaded from the local
filesystem, so presumably that means it has access to files on the local
filesystem and can disclose them to a third party. This would be a violation
of the same-origin policy, since the PDF is coming from a network origin and
shouldn't be able to touch local files.

I'm not totally clear on this though, since usually file:// is treated
specially to avoid security exploits. Maybe PDF.js is loaded from a local
filesystem origin that doesn't have those restrictions (chrome:// or something
equivalent)

------
LaSombra
I believe the upstream pdf.js fixed this already,
[https://github.com/mozilla/pdf.js/](https://github.com/mozilla/pdf.js/).

------
ikeboy
Why are they linking to private bugs?

~~~
mook
Mozilla often opens up security bugs after a while (when they feel like
everybody's been patched), so that can be useful when looking at the advisory
page in the future.

Sometimes things end up forgotten, though, since that seems to be a very
manual process.

------
surrealize
pdf.js was a pretty cool hack, but I wonder if it's time to integrate pdfium.

edit: I meant "hack" in the "cool application of technology" sense.

~~~
JoshTriplett
Moving from code _inside_ the browser sandbox to code _outside_ the browser
sandbox seems like a bad idea. (Chrome's integrated PDF support runs in a
sandbox despite being native code, but Firefox doesn't have equivalent native-
code sandboxes.)

~~~
pcwalton
Moreover, I'd take sandboxed JavaScript over sandboxed native code any day,
given the complexity of modern browser IPC and how much kernel surface area
tends to be exposed even to sandboxed processes on Windows and Mac.

~~~
JoshTriplett
Modern browser IPC is what backs JavaScript as well as sandboxed native code,
so that's not going to save you. Windows/OSX issues aside, on Linux I'm more
comfortable with seccomp-bpf than with a sandbox that's based solely on
assuming an absence of security holes in a JavaScript virtual machine.

~~~
pcwalton
Oh, I don't want to argue that unsandboxed JavaScript—and by this I mean
unsandboxed at the OS level—is more secure than sandboxed C++. (Now I think
there's a reasonable case that it is when compared to the sandboxes on
Windows/Mac, but that's debatable and I'm certain that people with more
expertise in security than I have disagree with me.)

My point is that I prefer having the JS VM _and_ the OS-level sandbox, as
opposed to just the OS-level sandbox.

Regarding IPC, I think there's a difference in terms of surface area between
being able to call the Web APIs and being able to send arbitrary bytes (and
shmem, etc.) across the named pipes/file descriptors.

