Vulnerability reported in Foxit PDF plugin for Firefox – how to mitigate it

When you think of PDF vulnerabilities and exploits, the first word that comes to mind is probably Adobe.

That’s because Adobe’s PDF reader has long been the most prevalent product in the marketplace, and the most heavily targeted by attackers and researchers.

But there are plenty of challengers in the PDF software market, and it’s important to remember that just “being different” is not enough to deliver security on its own.

Also, since Adobe released Reader X, with its security-oriented sandbox, crooks and researchers alike have found Adobe’s PDF nut much harder to crack.

You can therefore expect other vendors of PDF software to start feeling some of the heat that would probably have been aimed entirely at Adobe in years gone by.

Here’s an example: Italian security researcher Andrea Micalizzi has recently sought, and found, a possibly-exploitable vulnerability in the latest Foxit PDF plugin for Firefox.

Micalizzi hasn’t actually produced a proof-of-concept exploit, but I was able to reproduce his result at will.

(I used Firefox 18.0 with Foxit Plugin on Windows XP3.)

The crash, which is a side-effect of a stack overflow, pretty much lets you write to a memory location of your choice. That’s not good.

Foxit openly promotes its PDF reader as a secure platform that “insures worry free operation against malicious virus [sic]”, which may sound like a bold statement in the face of Micalizzi’s bug.

But there is still literal truth in Foxit’s claim: the bug is not in the PDF reader itself, but in the npFoxitReaderPlugin.dll file that acts as the glue between the browser and the reader.

→ The np at the start of the filename stands for “Netscape Plugin”, a plugin architecture that originated in the heady days of Netscape Navigator. Ironically, the first example of such a plugin for Netscape was written at…Adobe Systems.

Intriguingly, you don’t actually need to feed Foxit a PDF to provoke the crash. You just have to feed it a malformed link that, when clicked, serves up an HTTP reply that advertises itself as a PDF.

The buffer overflow happens in the code that processes the link, triggering a crash when the link includes an overly-long query string.

If a link contains a question mark [?], the query is the text that follows it. The query component is usually used to identify parameters submitted to a server-side script. Below, for example, the query part is the string download=true:

Foxit has yet to comment on this issue on its security advisories, though I am sure it will soon do so.

I’ve seen stories online suggesting that, since there’s no patch yet, you might consider switching to a different PDF reader.

But since the bug isn’t in the reader itself (and there’s no exploit yet, anyway), there’s a quicker and simpler mitigation you can use that will let you stick with Foxit.

Just turn off the Firefox plugin.

Go to Tools|Add-ons at the Firefox menu, choose the Plugins tab and click the Disable button against the Foxit Reader Plugin for Mozilla.

PDF files will no longer open directly inside your browser. You’ll get an intermediate dialog saying:

You have chosen to open: . . .

You will then need to click the OK button.

This loads the file into a separate Foxit reader process, avoiding the buggy code in the plugin DLL.

As Steve Jobs might have said, not that big of a deal.