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)
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.
It's not a private bug, it's a security bug. That means that anyone that is trusted by Mozilla to access this kind of bug, or that is explicitly added to the list of people allowed to access this bug can see it.
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.)
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.
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.
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.
PDFium wins on functionality and performance; I thought pdf.js won on security but this vulnerability makes me wonder. If PDFium and pdf.js are on par (or even close) security-wise, in my view that tilts the tradeoff toward PDFium.
Do not mentally categorize software into "has never had a vulnerability" versus "has had vulnerabilities" buckets. Especially for software as widely used, and as closely scrutinized, as browsers.
> Do not mentally categorize software into "has never had a vulnerability" versus "has had vulnerabilities" buckets.
Right. Software that has never had a vulnerability is either 1) software that has never had careful scrutiny, 2) software that has no potential security implications whatsoever, or 3) software that has gone through some formal verification and proof process (exceedingly rare).
I don't think I did. Security is obviously not a black-and-white thing, and my words "on par" and "close" are entirely consistent with a shades-of-grey view.
Nonetheless, the posterior distribution shifts based on new evidence.
Are you making a claim about which one is more secure? I'm genuinely curious about how they stack up against one another. pdf.js is obviously managed code, which I'm sure helps. But it also seems like it has less person-power behind it, now and historically. Do you agree with that perception? Why or why not?
But I don't think that it's particularly relevant to security whether 3 people or 30 people work on a project. Both Chrome and Firefox are fully maintained with top-notch security teams.
