PDF.js And Chrome – A Match Made In Heaven?

PDF.js is a Mozilla project built with the purpose of reducing trusted code by having PDF files handled by the Javascript renderer. This means that instead of having a separate plugin built in C++ there’s just the same old javascript renderer, no need to build on potentially exploitable code.

It’s a great idea and it works on a very simple principal that should always be held true – reduce attack surface where possible.

This isn’t some kinda amazing security thing though. JavaScript renderer exploits happen all the time, in fact that’s probably where they’re most likely to happen. Firefox also doesn’t implement some important mitigation techniques for JIT hardening (things like ASLR/DEP don’t apply here) though that’s more complex and when you look at their architecture it’s difficult to really say how important it is.

As PDF.js is entirely in Javascript it can theoretically run in any browser that supports Javascript, like Chrome.

The renderer is the ‘exposed code’ in this situation and Chrome runs its renderer at Untrusted Integrity. That means it has no file access. So even if a PDF exploits PDF.js in Chrome it’s trapped in the most restricted part of the browser and there’s really nothing it can do – it can’t read or write anywhere so even in-browser attacks are limited.

As it stands PDF.js works in Chrome but there’s no extension/plugin for it yet. Someone get on that – I want.

8 thoughts on “PDF.js And Chrome – A Match Made In Heaven?

  1. I’m having trouble making sense of your post. In any browser, PDF.js is no less secure than any other piece of java script.

    I’ve never heard of a “JavaScript renderer exploit”, can you please link to an example.

    • Hi Mike,

      PDF.js is “safe” because it doesn’t increase the trusted code base of the browser.

      With a separate PDF plugin you increase the size of your code and therefor you’re very likely increasing the complexity of the code; you get more vulnerabilities with more code. So having a separate PDF plugin means having a whole new area to exploiit.

      By rendering PDF documents within the Javascript Runderer you minimize the amount of code that can be exploited. The renderer already exists, that code is there, so if you’re not adding to it you’re not increasing the number of vulnerabilities.

      With a browser you have your Javascript Renderer taking in untrusted code. It’s for this reason that Chrome runs the renderer process at the absolute lowest rights possible – it’s the most exploitable part of the browser’s system (ignoring plugins like Flash/Java).

      I can probably find some CVEs with Google but I’m currently on a trip.

  2. Pingback: PDF.js For Chrome - It Works! - InsanityBit

Leave a Reply

Your email address will not be published. Required fields are marked *