6 ms·

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.

pcwalton 11y ago
That would be the wrong conclusion to draw from this exploit. PDFium has had vulnerabilities too.
- surrealize 11y ago
  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.
  - pcwalton 11y ago
    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.
    - JoshTriplett 11y ago
      > 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).
    - surrealize 11y ago
      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?
      - pcwalton 11y ago
        I don't know how many people work on PDFium. 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.
JoshTriplett 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.

pcwalton 11y ago

That would be the wrong conclusion to draw from this exploit. PDFium has had vulnerabilities too.

surrealize 11y ago
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.
- pcwalton 11y ago
  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.
  - JoshTriplett 11y ago
    > 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).
  - surrealize 11y ago
    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?
    - pcwalton 11y ago
      I don't know how many people work on PDFium. 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.

JoshTriplett 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.