Is Firefox's new JavaScript support within PDF files a security concern?



  • Historically, we have learned that many security vulnerabilities and exploits have resulted from allowing document files to contain executable code, whether it be JavaScript, VBScript, another scripting language, or even macros.

    As such, since the first days that JavaScript could be embedded into PDF files, I have disabled JavaScript support within every PDF reader and editor I have used. Many colleagues have done the same.

    According to the pre-release notes for Firefox 88, which is being pushed to the public any hour now:

    We [Mozilla] keep on working on improving our PDF forms support and now support JavaScript embedded in PDF files (some PDF forms use JavaScript for validation and other interactive features). If you find any bug with this feature, please file an issue on the PDF.js repository.

    On the surface, this sounds quite concerning from a security standpoint. Although, hopefully, any code executed from a PDF file will have at least the same security in place as JavaScript run from a website, the source and control of PDF content being loaded is often very different than a website.

    For example, let's take google.com (as Henny Youngman would add, "please"). Assuming a non-compromised connection, any JavaScript code running on that domain would be written by Google developers (for better or worse). But if you perform a search for PDF files on google.com, you'll be presented with literally billions of PDF files, each of which could be written by any random person. And each could contain JavaScript code written by literally anyone. With PDF JavaScript support enabled within the browser, any PDF file you click on to read could now run arbitrary code on your computer.

    Is this a security concern? And if so, can it be disabled?



  • Regular folks don't have to worry about this feature more than any other part of Firefox. For a professional worrier like myself (I literally get paid to worry) it's less concerning than JavaScript in a web page because of the lack of functionality.

    JavaScript in PDFs has an extremely limited set of objects it can manipulate: just the form data. It can't access or manipulate the document text, nor does it have access to any DOM (browser) APIs and can't send network requests. In addition, Firefox has always opened PDF files in a special local context and it's no longer considered part of the site the file was downloaded from. We still show that original URL in the address bar for convenience (you might want to copy it, or manually edit it to a related URL) but it's pretty much a lie. Even if the script could get out of the sandbox through some security bug--and this sandbox has been in use for years with Web Extensions--it wouldn't be able to affect the site it was uploaded to.

    The one new potential is that a jerk could write an infinite loop and try a denial of service attack, but that's not any different from any web page or framed web advertisement you browse to all day. It doesn't seem to be a problem in practice given equally "vulnerable" PDF viewers in Chrome, Edge, and Opera. You can always just close the tab as you would with a bad web page.

    You can turn it off if you want with the pdfjs.enableScripting pref, but there's no real reason to do so.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2