
50 CVEs in 50 Days: Fuzzing Adobe Reader - myinnerbanjo
https://research.checkpoint.com/50-adobe-cves-in-50-days/
======
technion
As much as many of us lament the state of much of today's software, if you
think of products from a certain era - IE6, Flash, Java web applets - they all
had a commonality in their code quality. These are mostly a non-issue these
days, but it's not because they suddenly stopped having bugs and still get
active use.

I remember rolling out Adobe Reader in those days and as a product, I don't
believe its core has changed much. They've certainly managed to bolt on a
whole lot of new features, but that can only make the position worse.

As much as this sounds like a call to kill Adobe, something needs to happen
before that's feasible. For the average enterprise, Adobe Reader is far more
ingrained than these products were. Case in point, in organisation I asked the
question of whether Chrome's PDF viewer would cut it for them. One large
department then ordered Adobe Professional for every user. They told me they
didn't need it, they just knew I wouldn't propose removing a product they'd
actually paid for.

Adobe Reader needs its HTML5 moment - an alternative that's not just "good
enough for most people", but one that's actually better.

~~~
wongarsu
To be fair, in my experience Chrome's and Firefox's PDF viewers don't cut it.
They are good for a quick preview, but especially when printing they
occasionally render things slightly wrong, which is unacceptable for a file
format whose entire point is to look the same everywhere. Also forms.

That doesn't mean that there aren't any alternatives. Foxit for example is
pretty good. But in-browser alternatives just aren't there yet

~~~
throwaway12iii
pdf.js has had 26 pull requests merged in the last month. 5,622 additions and
6,991 deletions. That's just in the project directly, not in the dependencies.

Since it's such a quickly evolving project, I wondered where form support is
up to.
[https://github.com/mozilla/pdf.js/issues/7613](https://github.com/mozilla/pdf.js/issues/7613)

Form support is not complete. Seems like it required quite a rewrite to get
the foundation in a good place to finish it off.

Are there rendering bugs? Yes. See plenty here:
[https://github.com/mozilla/pdf.js/issues](https://github.com/mozilla/pdf.js/issues)

Of course, Acrobat also has PDF rendering bugs, and other various bugs apart
from the security issues mentioned (their JavaScript implementation for
example).

As for printing... browsers aren't even good at printing HTML. The best
browser for printing is based on the old Opera software(PrinceXML), and Safari
is probably second. Remember the Apple display system used to be based on PDF
rendering... and they do a lot with CUPS and graphic designers.

However, printing PDFs on many browsers can go directly to the printer or the
OS (which mostly all support rendering PDFs directly now).

~~~
saagarjha
> Remember the Apple display system used to be based on PDF rendering

Does Quartz not still try to match PDF in the way its render structure is
composed internally?

------
TeMPOraL
Being able to run JS in a PDF sounds scary to a lot of people, but I wouldn't
throw that idea out entirely.

If you follow the work by Bret Victor & others on "explorable
explanations"[0][1] and interactive scientific papers[2], you probably
appreciate the need for a self-contained format for interactive documents.
Could PDF be this? I don't know, I hear the spec is too scary. But I'd say we
should have something like that.

\--

[0] - [https://explorabl.es/](https://explorabl.es/)

[1] -
[http://worrydream.com/ExplorableExplanations/](http://worrydream.com/ExplorableExplanations/)

[2] -
[http://worrydream.com/ScientificCommunicationAsSequentialArt...](http://worrydream.com/ScientificCommunicationAsSequentialArt/)

~~~
jeeceebees
Distill[1] is another example of interactive scientific papers (with a focus
on machine learning).

But is there really a good reason to not just keep these in browser? I don't
really know if there's much value in reading these locally. Maybe this would
be a good fit for an electron app?

[1] [https://distill.pub/](https://distill.pub/)

~~~
MayeulC
I would like HTML files to mostly replace pdf documents. However, they lack a
couple things:

* A way to save back form data. I believe google is working on a js api to access local files (given a few conditions). * A way to bundle the html with every js script, ressource, css, etc, in one file, without making a huge mess.

If you had a tar.gz with an index.html inside, and the browser was to
transparently allow r/w access to the archive contents from contained js
scripts, this could solve a lot of use cases (heck, even "electron" apps could
be replace by this). One exception being printed documents (postscript), at
which pdf is quite good.

~~~
nuclx
I'm in the same boat with browser-based vs electron apps (see my question
[1]). I don't think PDF-based forms are an alternative to reactive web forms
though, as they aren't dynamic enough. The sole purpose of PDF is page-
oriented print, which html(+js) can't deliver.

[1]
[https://news.ycombinator.com/item?id=16773933](https://news.ycombinator.com/item?id=16773933)

------
rixrax
I recall listening to a presentation in RSAC around 2013 or 2014 where Adobe
CISO or CIO or someone pretty much said that they don’t give fucks about
product security. E.g. zero impact on sales. I suspect it was thrown in as a
bit of trolling attempt in a conversation but looking at their track record
maybe that is the reality.

~~~
eganist
> they don’t give fucks about product security.

More accurately stated as "we sandboxed it, so anything discovered is less
likely to be critical." [https://www.adobe.com/devnet-
docs/acrobatetk/tools/AppSec/sa...](https://www.adobe.com/devnet-
docs/acrobatetk/tools/AppSec/sandboxprotections.html)

I've heard a variant of that talk delivered by a non-C-level at an
appsec/prodsec-focused conference where the rehashed quote above (though I'm
blatantly paraphrasing) was the justification used. Something more closely
reflecting the truth might be "we can't realistically tackle the many security
defects in Acrobat and Flash, so we sandboxed both applications instead to
generally reduce the technical risks posed by any vulnerabilities in code."

~~~
saagarjha
Except somehow we still end up with horrendous security vulnerabilities in
both. Putting things in a sandbox does not necessarily mean that you did it
correctly.

~~~
rixrax
Exactly this. Thank You.

------
devy
Honest question: why can't Adobe hire product security engineers to do this
kind of vulnerability discoveries or even hire 3rd party consultants to fix
bugs/vulnerabilities before they even get into production?

Every CVEs exposed by outside 3rd parties like this is a shame on their
software quality and reputation, IMMO.

~~~
Bhilai
This is a great question and I have thought a bunch about it and the only
conclusion I could make is that they dont care enough. This kind of news does
not affect Adobe's stock price or their profits. Their users probably mostly
don't care. So why bother paying $$$ for security engineers.

~~~
devy
If important zero-day affected by Adobe software causing rippling effects
perhaps they will care more? At this quality and enough time, it probably is
bound to happen.

------
fghtr
If you have a PDF document on your web site, please consider putting a link to
[https://pdfreaders.org/](https://pdfreaders.org/) instead of unfair
advertisement of Adobe Reader.

~~~
danieldk
Which gives (except for pdf.js) more PDF readers written in C, some with a
long history of CVEs, and typically not sandboxed by default.

Since many people are using a PDF reader to read PDFs from relatively
untrusted sources, do yourself a favor and at least use a reader that does not
have full system access.

macOS: Preview.app (uses macOS sandboxing)

Linux: Evince Flatpak on Wayland (Flatpak uses sandboxing. Wayland because X11
apps can read all keystrokes, mouse events, do screengrabs.)

Windows: no clue

All platforms: in-browser PDF reader with a browser that sandboxes.

~~~
rvp-x
If you're counting on wayland to sandbox arbitrary code execution, you're
getting in trouble.

~~~
Spivak
Applications that can send commands to X.org servers can completely control
it. The same isn't true for Wayland.

Flatpak is providing the actual application sandboxing, but being allowed to
talk to the X server is a huge amount of privilege that can't really be
restricted.

------
devwastaken
It's amazing browsers have so far decided to just not have an HTML archive
format that could replace PDF. The majority of what PDF does can be better
done in a webpage. Why not just an extension like .phd but is actually a
.tar.gz that contains a webpages assets. Present like pdf's are, and done.

~~~
saagarjha
PDFs are supposed to look the same on every computer. Webpages can’t do that
yet.

~~~
devwastaken
I don't know how accurate that is for PDF's, but webpages are supposed to look
the same, and given known compatible styling, it should be on any modern
browser. Browsers are extremely consistent in content presentation, that's why
webpages from early 2000s still look the same.

~~~
megous
No. Take for example font-family: sans-serif. That can look like anything, can
have different widths on different devices, etc. Browser windows can have any
size, devices can have various pixel densities, users can work at different
zoom levels, etc. The previous big thing was responsive design.

~~~
arianvanp
Same counts for PDFs. If the font isn't shipped inside the bundle, the PDF
will look like shit.

~~~
megous
Good point. I noticed that too. At least web pages are made so that the
content is re-flown [seems like the whole point], so it doesn't look like
shit. It seems like [many?] PDFs place each character separately so if the
actually used font is different from the one used during creation, the result
will look very messy.

------
lbriner
Acrobat Reader has been the poster boy for poor software for many years and it
appears that Adobe have been good at adding new features to make it largely
impossible for their competitors to keep up.

What is one to do?

Surely, the obvious answer is to ringfence PDF (or another new format) for the
most basic features. These could more easily be handled by 3rd-party apps both
securely and to render correctly. Let Adobe do whatever they want with their
own format by adding loads of stuff people don't want, then the sell is harder
for them:

Get a cheaper, safer app for writing portable docs which can do most things or
pay more money for a very insecure format that does stuff you don't need.

I assume that others have attempted at some point to make an OSS alternative
to PDF and I'm guessing it hasn't worked yet?

~~~
tonyedgecombe
That is sort of what PDF/A is:
[https://en.wikipedia.org/wiki/PDF/A](https://en.wikipedia.org/wiki/PDF/A)

------
agumonkey
What about having continuous fuzzing servers for just about any software ?
kinda like virustotal.

~~~
arkadiyt
Google does this with their oss-fuzz project (only for open source projects,
since as Someone1234 noted it's very difficult otherwise):

[https://github.com/google/oss-fuzz](https://github.com/google/oss-fuzz)

~~~
touisteur
Microsoft had 'project Springfield' which became 'Microsoft Security Risk
Detection' ([https://www.microsoft.com/en-us/security-risk-
detection/](https://www.microsoft.com/en-us/security-risk-detection/)). Kind
of like Fuzzing as a Service.

Anyone on HN has any experience to report with this ?

------
aisofteng
What a strange bar graph, where each column is color coded to a year rather
than just putting the years on the x axis.

------
xvilka
Since KDE, GNOME, and FSF foundations recently got a significant contribution
this year, I wonder why they wouldn't join forces and hire a couple full-time
developers to make poppler and all poppler-based PDF viewers (Evince, Okular,
etc) actually useful for PDF Forms, animated and interactive content.

------
mitchtbaum
Adobe's software is large enough and ingrained deep enough that it seems
people give it a pass with today's standards for software stability. Lowering
the threshold of well-shaped review nearer to git and libgit2 would yield even
more value toward stepping through the software stargate.

Git total loc: 279,993

libgit2 total loc: 219,887

Git CVEs (so far): [https://www.cvedetails.com/vulnerability-
list/vendor_id-4008...](https://www.cvedetails.com/vulnerability-
list/vendor_id-4008/GIT.html)

libgit2 CVEs (so far): [https://www.cvedetails.com/vulnerability-
list/vendor_id-1606...](https://www.cvedetails.com/vulnerability-
list/vendor_id-16066/product_id-35762/Libgit2-Project-Libgit2.html)

------
AnaniasAnanas
Do people still use Adobe reader nowadays? Last time that I tried it in my
school's library it took half a minute to load and render my document, and
after that the whole UI was unresponsive.

I had a much better experience with Sumatra on windows and Zathura on Linux
where my documents open almost instantly.

~~~
mistrial9
.. tried Zathura on LUbuntu just now for the first time ; appears to be a VIM
for documents viewing or something.. no interest in Zathura here!

~~~
kvakil
and just like that, you've convinced me to install it. Different strokes for
different folks, I suppose. :)

~~~
schoen
I was also convinced to install it, although after trying it, it looks more
like less for PDFs than vim for PDFs (as many of the commands search or scroll
in complex ways, but none of them _modify_ the PDF).

Still, it's interesting to have something like less for PDFs!

~~~
jgtrosh
IMO mupdf is the real less for PDFs. It is so lightweight and straightforward
it makes everything else seem terribly bloated.

~~~
omaranto
Zathura can use mupdf as its PDF renderer (it can also use poppler). I like
using the mupdf library through Zathura rather than using the mupdf
application, because Zathura has plugins for other file formats too, like
PostScript and DJVU, and that way I learn a single set of keystrokes to view
all sorts of documents.

------
herodotus
I may have missed something, but it looks to me like this is really a test of
just the JPEG 2000 part of Acrobat Reader. It is possible that Adobe built
this part of the reader by taking some open source implementation of JPEG 2000
(such as the reference implementation), and modding it - probably by changing
memory allocation to be consistent with ARs memory model. So it is possible
that some or many of the discovered vulnerabilities are in fact part of the
JEPG 2000 library, in which case the problem goes beyond Adobe Acrobat.

~~~
nwmcsween
You missed something, the article says at the end they fuzzed many different
parsers not just the jpeg2000 one

~~~
herodotus
Ah - thanks

------
1024core
Oh no, not Adobe again! This company has been putting out shitty (in terms of
security) for 20+ years. Anyone remember Adobe Flash? (shudder)

------
time-domain0
If you read the PDF spec from the late 90's, it is Stephen King novel-scary...
container format, multiple encodings, encryption, embedded binaries, embedded
JavaScript and more.

~~~
zubspace
While working with the PDF format I sometimes get the impression that this
complexity is what Adobe wants. As a result, Adobe Reader is the only viewer
that implements the entire spec and can handle all (or most) quirks.

This is especially apparent when trying to edit arbitrary PDF files, which is
sometimes not so easy or even impossible. Just the definition of fonts and the
text layout is already so complicated that this is the logical consequence.

But perhaps the format has simply grown and led to additional requirements
such as PDF/A, PDF/X, PDF/E and now PDF 2.0, the next standard that makes
everything even more complex... Will this every stop?

~~~
SmellyGeekBoy
The same could be said for the Microsoft Office file formats.

Or PSD, for that matter.

~~~
tonyedgecombe
The Office formats are well specified, they are complex because that is the
nature of the software but it is a world away from something like PSD or even
PDF.

~~~
gpvos
PDF is actually quite well specified, there are not many holes in the
specification itself.[0] As to what Adobe Reader will do when it encounters an
out-of-spec file, that is a lot fuzzier.

On the other hand, the Office file formats (especially Word) have many un- or
underspecified cases.

[0] The only one I know of is finding the end of compressed inline image data.

~~~
tonyedgecombe
I found quite a few areas that were vague when I was working with it.

The advantage of the office formats is they are Zip files with a ton of XML,
ie they are well defined. The application parts are another matter of course.

~~~
BlackFingolfin
Just because something is XML doesn't mean it is "well-defined".

~~~
tonyedgecombe
No, but XML parsing is a solved problem, PDF parsing isn't.

~~~
tinus_hn
The original criticism was that some parts are just binary blobs encoded in
XML elements, which wouldn’t suprise me at all, with Microsoft being allowed
to tick the ‘XML file format’ checkbox and still getting to keep the binary
format advantages.

------
brabara
Wonder how many of these were already in use by state actors?

------
brian_herman
Awesome work!

------
peteretep
I feel like if you’re a corporate buyer of Adobe software, you’ve got grounds
for gross negligence here?

------
fulafel
The fact that companies still have the email-> employee pc -> acrobat reader
pipeline enabled says a lot about what companies really think about security,
posturing aside.

(home users too, but they can plead ignorance)

~~~
Angostura
The reason being that there are almost no high-profile breaches I can think of
where PDF vulnerabilities have been blamed. Unlike Office macros, Flash etc
etc.

