
Six year old PDF loop bug affects most major implementations - hannob
https://blog.fuzzing-project.org/59-Six-year-old-PDF-loop-bug-affects-most-major-implementations.html
======
plicense
PDFium used by Chrome internally uses Foxit PDF library to read and extract
information from the PDF.

Google basically bought Foxit's library and open sourced it - but looks like
the open source version isn't keeping up with the upstream commercial version
of Foxit because the latest Foxit reader doesn't seem to have this bug.

~~~
sebazzz
Wonder why they didn't go for pdf.js, since Chrome already has (had) superior
JS performance.

~~~
izacus
Because PDF.js doesn't come close to performance of native C++ code of pdfium
(our tests showed 3-10x slowdown).

~~~
pier25
Indeed. PDF.js works for simple PDFs but once you start adding complex
layouts, big images, vector graphics, etc, the experience becomes horrible on
mediocre hardware. At least the last time I evaluated it.

Hopefully Web Assembly will change this.

------
Semaphor
FWIW, I have no problems with the file in Sumatra.

[https://www.sumatrapdfreader.org](https://www.sumatrapdfreader.org)

~~~
_pmf_
Very underrated software. Incredible work from a single developer.

~~~
yoodenvranx
Yes, the website looks a bit sketchy and the GUI is a bit dated but the
software is top notch! If you need a small pdf/ebook reader then Sumatrapdf is
a very good choice.

------
timendum
Firefox 57 will contains the pdf.js version with this bug fixed
[https://bugzilla.mozilla.org/show_bug.cgi?id=1393476](https://bugzilla.mozilla.org/show_bug.cgi?id=1393476)

Also Chromium changes have been merged [https://pdfium-
review.googlesource.com/c/pdfium/+/12391](https://pdfium-
review.googlesource.com/c/pdfium/+/12391)

------
walterbell
What's the best way to check a few thousand PDFs for potential malware? Would
a Linux VM with SE Linux + minimal whitelisted operations on the PDF reader be
sufficient? Is there a sandbox equivalent for Windows or Mac, which could
detect attempts to break out of the sandbox?

~~~
arfar
QubesOS has a really nice solution for opening untrusted PDFs:
[https://micahflee.com/2016/07/how-qubes-makes-handling-
pdfs-...](https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-way-
safer/)

------
nathan_f77
That's good to know. I'm working on a service that processes PDFs, so I was
concerned that someone could bring down my server by uploading one of these.

The pdf-reader gem throws a "stack level too deep" exception after about a
second. There's also a ton of other issues on pdf-reader:
[https://github.com/yob/pdf-reader/issues](https://github.com/yob/pdf-
reader/issues)

Good reminder that any kind of file processing needs to be heavily sandboxed.

------
DrMoisheP
Though this file's bug did not adversely affect Sumatra or PDF-XChange, it
DOES crash Windows Search routine when it attempts to add loop-edited.pdf to
its index. Windows Explorer also crashed (and restarted itself successfully)
on trying to change the extension to avoid indexing. Renaming worked on the
second try. Download with caution!

------
WalterBright
> the test cases I provided never got added to the test suite.

I don't understand that. The test cases we fix (for D) always wind up in the
regression test suite. It would be impossible to move D forward otherwise.

------
_pmf_
Is is an actual bug does the exploit rely on certain legal PDF parameters that
cause quasi-infinite behavior when actually rendering it (i.e. the PDF
equivalent of a ZIP bomb)?

~~~
tyingq
It's circular references created via the "xref" portion of a PDF document. An
implementation that blindly chased a circular reference would be a bug in my
view.

------
carapace
Don't bury the lede!

> In the best cases the maintainers of the affected software take the bug
> triggering sample and use it in their test suite. I think this should be a
> standard practice.

> ... maintainers of parsers for common file formats could also take a look at
> their competitors and check their test suites.

------
kuschku
KDE’s Okular is interestingly not affected. This is at least the 3rd major PDF
bug this year where evince is affected, but not Okular.

Anyone have an insight into why evince seems to be so much more often
affected?

~~~
lower
Is evince actually still affected? The article says that it was affected
initially (i.e. six years ago), but that the bug has since been fixed.

Both Okular and Evince use poppler for pdf rendering, so they should both get
the fix from poppler.

------
amelius
> This isn't a major security issue, the impact is a denial of service.

Probably just denial of _your own_ service, not everybody else's.

~~~
yorwba
Anyone who tries to open the PDF with a naive parser will be affected.

For example, Google appears to crawl PDFs for their search index. If their
crawlers crash after exhausting their memory limit, and if those failures
trigger automatic retries, it would tie up a bunch of their resources they'd
rather allocate elsewhere.

Some anti-virus scanners probably also try to open PDFs, so if you can crash
them reliably, you'll be able to hide an actual malicious payload.

------
kencausey
MuPDF seems to be unaffected.

