4 ms·

Unless they changed programming language of Acrobat Reader to something memory safe, this will open a huge attack surface for drive by hacking. There's a reaso

Unless they changed programming language of Acrobat Reader to something memory safe, this will open a huge attack surface for drive by hacking. There's a reason why most browsers got rid of plugins (Java Applets, Flash, Acrobat, etc.)

btown 4y ago
Yep - even though Acrobat is the standard for PDFs on the desktop, there's a world of difference between "PDFs I download may be malicious" and "links I click and frames I load may be malicious." The idea that https://nvd.nist.gov/vuln/detail/CVE-2021-28550 https://nvd.nist.gov/vuln/detail/CVE-2021-28550 could have been exploited without requiring a download would have been a disaster. (Though, I should add, memory safety is by no means a guarantee of software being free of code-execution vulnerabilities... but it certainly does help!)
vsareto 4y ago
I imagine they'll run it in a sandbox, plus MS may help find vulnerabilities themselves
SigmundA 4y ago
While I don't trust Adobe to make secure software, the existing PDF viewer in Chrome/Edge is PDFium [1] which was licensed from Foxit [2] and is C++ and has had its share of exploits. There is PDF.js [3] used in Firefox but it has performance and printing issues due to it being purely done in javascript. Ideally the whole browser including the HTML and PDF rendered would be done in a memory safe language, but that will be awhile I suspect. I certainly don't want to go back to the activeX days and having to install a plugin to view PDF's. Don't really see the need for this change as its going back to a close source renderer and PDFium seemed to work well with all PDF's thrown at it unlike PDF.js [1] https://pdfium.googlesource.com https://pdfium.googlesource.com [2] https://en.wikipedia.org/wiki/Foxit_Software#OEM_relationships https://en.wikipedia.org/wiki/Foxit_Software#OEM_relationshi... [3] https://mozilla.github.io/pdf.js/ https://mozilla.github.io/pdf.js/
- sys42590 4y ago
  As a side note: Acording to mitre.org there are 107 CVE entries issued for PDFium since it got it's first entry in 2014. In the same years Acrobat Reader got totally 1678 CVE entries.
sidewndr46 4y ago
Yeah, this is exactly what I was thinking. Why not just bring back ActiveX?
kevincox 4y ago
The post links to a blog and the most recent post seems to address this concern. (I haven't actually read it yet.) https://microsoftedge.github.io/edgevr/posts/How-we-are-securing-our-new-PDF-stack/ https://microsoftedge.github.io/edgevr/posts/How-we-are-secu... Edit after reading: What a joke. They are using a better allocator and doing some fuzzing. This is nowhere close to the approach that Chromium uses which is basically running the PDF viewer via WASM.

btown 4y ago

Yep - even though Acrobat is the standard for PDFs on the desktop, there's a world of difference between "PDFs I download may be malicious" and "links I click and frames I load may be malicious." The idea that https://nvd.nist.gov/vuln/detail/CVE-2021-28550 https://nvd.nist.gov/vuln/detail/CVE-2021-28550 could have been exploited without requiring a download would have been a disaster. (Though, I should add, memory safety is by no means a guarantee of software being free of code-execution vulnerabilities... but it certainly does help!)

vsareto 4y ago

I imagine they'll run it in a sandbox, plus MS may help find vulnerabilities themselves

SigmundA 4y ago

While I don't trust Adobe to make secure software, the existing PDF viewer in Chrome/Edge is PDFium [1] which was licensed from Foxit [2] and is C++ and has had its share of exploits. There is PDF.js [3] used in Firefox but it has performance and printing issues due to it being purely done in javascript. Ideally the whole browser including the HTML and PDF rendered would be done in a memory safe language, but that will be awhile I suspect. I certainly don't want to go back to the activeX days and having to install a plugin to view PDF's. Don't really see the need for this change as its going back to a close source renderer and PDFium seemed to work well with all PDF's thrown at it unlike PDF.js [1] https://pdfium.googlesource.com https://pdfium.googlesource.com [2] https://en.wikipedia.org/wiki/Foxit_Software#OEM_relationships https://en.wikipedia.org/wiki/Foxit_Software#OEM_relationshi... [3] https://mozilla.github.io/pdf.js/ https://mozilla.github.io/pdf.js/

sys42590 4y ago
As a side note: Acording to mitre.org there are 107 CVE entries issued for PDFium since it got it's first entry in 2014. In the same years Acrobat Reader got totally 1678 CVE entries.

sidewndr46 4y ago

Yeah, this is exactly what I was thinking. Why not just bring back ActiveX?

kevincox 4y ago

The post links to a blog and the most recent post seems to address this concern. (I haven't actually read it yet.) https://microsoftedge.github.io/edgevr/posts/How-we-are-securing-our-new-PDF-stack/ https://microsoftedge.github.io/edgevr/posts/How-we-are-secu... Edit after reading: What a joke. They are using a better allocator and doing some fuzzing. This is nowhere close to the approach that Chromium uses which is basically running the PDF viewer via WASM.