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.

Comments

FUD News?

[RockoW]

So they are talking about a possibility of exploit and not an actual exploit....

Re:FUD News?

[amicusNYCL]

Why is the story specifically about Edge? Doesn't Chrome also have a built-in PDF reader? Is there something that makes Edge vulnerable in this case but Chrome isn't?

Ah, PDF - should have stopped at 1.5

[rsborg]

The PDF format v1.7 supports all sorts of crazy stuff (including javascript). Apple was sane, and IIRC, doesn't support PDF 1.7, probably only 1.5 (and not all of it - some features like pdf_packages and nested PDFs didn't work right in previous versions of OSX).

I thought that MS Word proved you shouldn't have script code in your (mainly recognized as printed text) file formats. Of course, leave it to Microsoft to re-learn their own history.

Unless you think they simply don't care about this shit.

Re:Ah, PDF - should have stopped at 1.5

[anss123]

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.

What's the vulnerability here?

[PhrostyMcByte]

Is there an actual bug in EDGE's PDF viewer, or are we just saying software can have bugs and that people will try to exploit those bugs?

"All an attacker needs to do..."

[nuckfuts]

"... is find and create a database of WinRT vulnerabilities...".

You mean the way any piece of software in existence could be exploited by "finding a vulnerability"?

Even the referenced article states that...

...because Windows 10 implemented former EMET features such as ASLR protection and Control Flow Guard, [this] "makes the development of exploits for WinRT PDF vulnerabilities time-consuming and therefore costly for an attacker."

So not only is this utter FUD, it's self-contradictory FUD.

For more information

[penguinoid]

For more information on the hack, click here [pdf]

Researcher's actual page

[qubezz]

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...

Re:And Firefox?

[NotInHere]

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.