Slashdot Mirror
Windows' Built-In PDF Reader Exposes Edge Browser To Hacking (softpedia.com)
An anonymous reader writes: Edge, Microsoft's new browser, uses the WinRT PDF library to automatically embed and present PDF files while navigating the web. This is what Java does with applets, and Flash with SWF files -- it unintentionally allows a hacker to append malicious code to PDF files and trigger drive-by attacks, which exploit WinRT vulnerabilities to target Windows 10 users. All that an attacker needs to do is to find and create a database of WinRT vulnerabilities it could leverage to distribute his malware.
Slashdot editors can't help themselves. Post original article? No, lets post a monetized site with two generations of dumbing-down.
At this week's RSA USA 2016 conference, I will be presenting my research on the attack surface and exploit mitigations in EdgeHTML, the rendering engine used by the Edge browser on Windows 10. One of the interesting features of EdgeHTML that I will discuss is its ability to use the built-in WinRT PDF Renderer library in Windows for rendering PDFs.
The feature is useful in that users do not need to install and maintain additional software for reading PDFs. However, the feature also opens up another attack surface that can be used to attack the Edge browser. This blog post takes a look at this library and its security implications.
https://securityintelligence.c...
In fact there is a difference that makes the PDF reader in Firefox more secure than the ones in Chrome or Edge: In chrome and edge, the PDF reader is a binary module, that's sandboxed some way from the other parts of the operating system, with that sandbox being the only protection mechanism.
In Firefox, the PDF reader is written 100% in javascript. Originally in fact it has been written by some guy who greatly improved the javascript JIT engine for firefox, and wanted to demonstrate how fast the javascript VM now has became, and that it can run "real" applications like PDF readers.
In fact, since the earliest days, the website for the firefox PDF reader featured his paper as example document: https://mozilla.github.io/pdf....
To get back to the topic: due to the fact that the firefox PDF reader only uses APIs and functionality that is already available in the web, viewing a PDF file isn't less secure than normally browsing the internet (without any addons that e.g. block javascript or something). So in theory the firefox PDF reader should be the most secure one, as there is no difference, and thus no additional attack surface.
However, there is a tiny part where the firefox PDF reader is different from normal js code, and it has been abused already once: https://blog.mozilla.org/secur...
It was no remote code execution bug, but it allowed websites to read files on your disk, that's pretty bad.
So yes, in principle the PDF reader for firefox is the most secure one.
Having written both a PDF and PS interpreter, I can tell you that PDF command streams (the stuff that tells the viewer how to draw the page) has no loops or variables. You can't do calculations, the closest being PostScript functions, but you can't directly use the output of such a function (it's used to calculate colors).
Now, to be fully PDF compliant, you must support a limited subset of PostScript commands. There at least you can do math, but loops need not be implemented, just a few math related operators.
In theory, Type1 fonts is just PostScript code, but PDF viewers never actually execute that code.
TrueType fonts have executable code that is executed, but I don't know if it's Turing-complete.
Of course, PDF v.1.7 allows for JavaScript.