A built-in PDF viewer component based on JavaScript and HTML5 Web technologies has been added to the beta version of Firefox 19, Mozilla said Friday.
The browser maker described the built-in PDF viewer as more secure and safer than proprietary PDF viewing plug-ins, like those installed by Adobe Reader or Foxit Reader. However, several security experts noted that it probably won't be free of vulnerabilities.
"For a number of years there have been several plugins for viewing PDFs within Firefox," Mozilla Engineering Manager Bill Walker and Mozilla Software Engineer Brendan Dahl said Friday in a blog post. "Many of these plugins come with proprietary closed source code that could potentially expose users to security vulnerabilities. PDF viewing plugins also come with extra code to do many things that Firefox already does well with no proprietary code, such as drawing images and text."
The built-in PDF viewer currently being tested stems from a Mozilla Labs project called PDF.js. "The PDF.js project clearly shows that HTML5 and JavaScript are now powerful enough to create applications that could previously have only been created as native applications," the Mozilla software engineers said. "Not only do most PDFs load and render quickly, they run securely and have an interface that feels at home in the browser."
Since the viewer uses standard HTML5 APIs (application programming interfaces) it can also run in different browsers and on different platforms, like tablets and mobile phones. A live demo of the viewer running as a Web application is available on the PDF.js website.
"The PDF.js powered viewer in Firefox Beta is the first step to it becoming a fully integrated feature within the release version of Firefox so its benefits can be enjoyed by all Firefox users," the Mozilla software engineers said.
Mozilla did not clarify whether this viewer will be used by default even in cases when a third-party PDF viewing plug-in is installed. The company did not immediately respond to a request for comment.
Security experts believe that the built-in PDF viewer will provide more security for users, but not necessarily because it won't be prone to vulnerabilities as third-party PDF viewer plug-ins are.
Such an implementation might provide more security to the end user because its user base will be smaller compared to that of Adobe Reader and cybercriminals will continue to focus on exploiting the most popular pieces of software, Stefan Tanase, a senior security researcher at antivirus vendor Kaspersky Lab, said via email. "While I am excited to see Firefox giving extra thought to the security of its users, what worries me is that even the technologies on which PDF.js is based can be vulnerable."
Tanase pointed out that vulnerabilities in the browser's JavaScript rendering engine are not uncommon. As an example, he pointed to CVE-2013-0750, a remote code execution vulnerability fixed in Firefox 18 a few days ago. The vulnerability stems from a bug in the way the browser calculates the length for a JavaScript string concatenation.
This vulnerability is not the exception, but rather the rule, Tanase said. "Similar ones are discovered every year, in mostly every product version and they can all be used by attackers to run code and install software, requiring no user interaction beyond normal browsing."
This PDF viewer component could be more secure than third-party plug-ins if it is written entirely in JavaScript/HTML5, Thomas Kristensen, the chief security officer at vulnerability intelligence vendor Secunia, said via email.
However, this doesn't mean that it's not prone to vulnerabilities, he said. "If new functionality has been added to the browser or the PDF reader otherwise becomes privileged in the browser, then it may be vulnerable and become a new vector to exploit these vulnerabilities in the browser."
"From a technical standpoint I find it very interesting that they are creating a PDF viewer that utilizes the existing capabilities of the browser," Carsten Eiram, the chief research officer at security consultancy firm Risk Based Security, said via email. "Since browsers are now so advanced with HTML5 and JavaScript support that they can actually parse PDF files, it could make having a separate PDF viewer pointless for most users, who just need basic PDF viewing capabilities."
In general, the less code there is on a system, the less exposed it is to potential attacks, Eiram said. Using this built-in PDF viewer component instead of installing a separate a PDF reader application that often includes features many users don't really need and which can be vulnerable, reduces the system's overall attack surface, he said.
Tanase also agrees with this theory. "There's a clear benefit for using the same rendering engine for both Web pages and PDFs which needs to be pointed out: the code base is smaller, therefore the attack surface and potential risk is lowered," he said.
Eiram believes that it will come down to how solid the JavaScript and HTML5 implementations are in the browser. "I would expect any vulnerabilities in these implementations to affect the PDF viewer too," he said.
Fortunately, if such vulnerabilities are found, the job of fixing them falls to the browser vendor. Browser makers, especially Mozilla and Google, have a very good track record of managing vulnerabilities and historically have had better updating mechanisms than third-party plug-in vendors, Tanase said.
