Looking at crazy stuff like this, I'm so glad most browsers can render PDFs natively and I don't have to rely on any Adobe software anymore.

The vastly lower attack surface in PDF viewers built into browsers has been quite frustrating for me.

I've seen Adobe vulnerabilities in the wild, and I've seen the improvements to an organisations security by removing Adobe Reader. Not to mention, the immediate reduction in labour of managing its colossal updates regularly.

However, try to remove Adobe PDF in a business with more than a few people, and ime, it's only a matter of time before you start getting demands for Adobe Reader. End users receive complex PDFs the reader in Chrome and Edge can't deal with more than tech people realise.

I hit this myself recently, having decided to spend a week learning TLA+, and finding the published Hyperbook is just totally broken without a third party PDF viewer.

Is Evince capable of displaying the complex PDF's you are talking about?

Evince is usually good enough, the problem that managing type people often like to make annotations in Acrobat and to open those you have to have Adobe stuff.

Edit: not to open maybe, but to see the annotations

Unfortunately, the PDF rendering in browsers is typically slow and limited in functionality, and often renders poorly on screen and hopelessly badly on a printer. Even basic functionality like showing 2-up layouts or handling forms seems to be beyond them.

Obviously there are legitimate concerns about security with browser plugins, but replacing them with half-baked built-in alternatives isn't going well so far.

OK, but then again: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome+pdf

This is a good exercise in learning why counting CVEs doesn't give you anything.

If you look closer at the pdfium vulns (I reported some of those) they include all kinds of "safety violations" with unclear impact. E.g. integer overflows, invalid memory reads etc. Many of those are simply undetectable without source-level check tools (mostly the C sanitizers).

The Chrome team has a policy of counting a lot of stuff as vulns if it "could" cause a security issue. This is good - better safe than sorry. But it blows up their CVE count and makes them look bad for people doing bad statistics.

Versus Firefox': https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pdf.js

Firefox is so utterly underrated these days. Such a shame. It's a good browser which puts the user in control and just gets the job done.

They've been moving away from that though, try changing your user agent or disabling JavaScript.

Agreed, they are moving with what's popular. I'm just afraid it's necessary to keep market share. When moving browsers people allow a lot more disruption compared to when a browser gets an update. To move forward, old thing probably have to break... or at least, that's what I like to believe because otherwise Firefox is becoming shit.

Count the instances of "arbitrary code execution" for chrome vs adobe. Its a huge improvement! Granted its not just the pdf reader in the case of adobe.

Huh. I had assumed PDFium ran in the NaCl sandbox or similar. Is that not the case?

How does Adobe allow this to happen? After enough of these over time, you'd think they'd fine some way to invest majorly in securing their runtimes.... either via another language like Mozilla is doing with Rust, some provably secure math-vm-thingie like Microsoft Research, massive security reviews & reduction of attack surfaces like OpenBSD, or another CS-driven solution.

Adobe would definitely profit from languages such as Rust. But they are not a "tech" company in the traditional sense anymore, I don't see them investing in anything that doesn't yield high short term returns. It's a big company that dominates the "creative" market, because it can impose its formats on an industry that does not care about open technologies.

Rust isn't a cure-all for every security issue.

True, and there are lots of security exploits that are caused by logical error, but the majority of those CVEs are caused by memory corruption, use-after-free and out-of-bounds memory corruption.

All errors avoidable in Rust, as well as other safe languages, outside unsafe blocks.

But if you look at those CVEs, it is something that would prevent a majority of those issues. Use after free, boundary errors, etc.

Their customers don't care and they are not altruistic like Mozilla or OpenBSD.

When Flash and Acrobat go away completely, Adobe most certainly does care because it has lost its customers.

Apparently people on HN aren't aware that nowadays Flash compiles to native code and used in many mobile games

http://www.adobe.com/devnet-apps/flashshowcase/#/main

As for Acrobat, it is daily used across all our Fortune 500 customers.

Keywords for the safety minded ones:

- exploitable memory corruption

- exploitable heap overflow

- exploitable use after free