Critical Vulnerability in Firefox Built-in PDF Viewer


When everyone talks about how risky the Web is, most of us think in terms of exploits that attack vulnerabilities in content like JavaScript, which peaked in 2013, and Flash, which has been a dominat vector of attack so far this year. The fact that PDF and Microsoft Office documents like Word & Powerpoint permeate the web is something that we don't often notice - until a critical vulnerability like this one shows up.  Popular browsers like Chrome and Firefox contain built-in viewers for PDF, which enables document viewing to blend seamlessly with our native Web experience. But easy document viewing can come at a price:  A simple click can lead to a document that's potentially weaponized and laden with malware.

Firefox Built-In PDF Viewer

Firefox ships with a built-in PDF viewer (PDF.js) that replaces Adobe's Acrobat Reader. The motivation behind this is "to create a general-purpose, web standards-based platform for parsing and rendering PDFs". Because the viewer is written in JavaScript, hackers found a way to exploit an origin policy violation to access local files. There's an entire thread on Hacker News around this vulnerability and here are some noteworthy comments:

  • "The real question is why the he$! is Firefox not sandboxed?"
  • "I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given?"
  • "Run the browser in a container or in a sandboxed environment"
  • "Time to start running everything in it's own container"

As usual the, Hacker News crowd has some creative ideas here. On my last read of the thread I saw 20+ references to sandbox and containers, and about 30+ references to Docker. The underlying theme and call to action in the posts is consistent. It's about Isolation, which keeps content from the Web completely away from the endpoint.

Isolation is a very appealing concept, but until now it's been difficult to implement on a broad scale.  One major question is where to do the isolation.  Deploying endpoint software to do isolation has been tried with limited success owing to issues with device, OS and application dependencies, as well as the headaches involved in deploying endpoint software.  Isolating and executing content away from the endpoint avoids these issues, but the challenge then is to deliver a hi-fidelity experience for users that doesn't look like VDI or break their native experience. 

We've worked really hard to address this in the Menlo Security Isolation Platform. With Menlo Security Document Isolation, a cloud service deployed as a simple proxy, we intercept links to documents that you click (PDF or Microsof Office Documents) and in real-time convert these to HTML5 which is delivered, malware-free, to your device. The end result completely preserves the overall appearance of the source document. However any code, macros, etc. (including potential malware) is completely stripped off in the process and never reaches the user. Best part? Deployment takes all of a few minutes and you can be up and running. So everyone on Hacker News (and beyond) can take heart - there is a way to eliminate malware risk from Web documents, without needing any changes to your browser or any other software on your device.  It's called the Menlo Security Isolation Platform, and it's available now.

Tags: malware, isolation, pdf, firefox

Connect with us

Lists by Topic

see all

Recent Posts