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.