5 ms·

Six year old PDF loop bug affects most major implementations

109 points by hannob 9y ago

amelius 9y ago
> 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.
- kalleboo 9y ago
  Well you could imagine someone uploading a ton of files with this bug to some service that generates thumbnails of PDFs files and overwhelms it
- willvarfar 9y ago
  And potentially a DOS of web-scrapers that download and try and do anything with them, and a DOS of online services that allow users to upload PDF and do something with them. Does your mail client show a thumbnail preview of PDF docs you receive? Will your mail client get stuck in an endless loop trying to thumbnail a malicious attachment and so on?
- yorwba 9y ago
  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.
plicense 9y ago
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 9y ago
  Wonder why they didn't go for pdf.js, since Chrome already has (had) superior JS performance.
  - izacus 9y ago
    Because PDF.js doesn't come close to performance of native C++ code of pdfium (our tests showed 3-10x slowdown).
    - pier25 9y ago
      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.
  - gcp 9y ago
    There's a long tail of PDF documents that use obscure PDF features that pdf.js doesn't entirely handle correctly.
  - Theodores 9y ago
    They probably don't care. All they needed was that aspect covered so that things like ChromeOS could have the functionality. They went for the guaranteed to work solution rather than reinvent the wheel. Okay, the more developed solution. I do not remember seeing PDF documents when I was last buying Google hardware, my impression is that Google don't see a future in the format, it is mere printer driver to them, not where the party is at.
  - deleted 9y ago
    [deleted]
  - TazeTSchnitzel 9y ago
    I believe pdf.js is newer than the Chrome PDF viewer.
  - SigmundA 9y ago
walterbell 9y ago
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?
- Theodores 9y ago
  Just do the actual work on a Chromebook, as designed for a 10 year old and complete with rock solid WiFi for £200. Problem solved.
- arfar 9y ago
  QubesOS has a really nice solution for opening untrusted PDFs: https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-way-safer/ https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-...
Semaphor 9y ago
FWIW, I have no problems with the file in Sumatra. https://www.sumatrapdfreader.org https://www.sumatrapdfreader.org
- _pmf_ 9y ago
  Very underrated software. Incredible work from a single developer.
  - yoodenvranx 9y ago
    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.
  - GeekyBear 9y ago
    I agree. It's small (both in file size and system resource usage), fast, and works very well.
_pmf_ 9y ago
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 9y ago
  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.
nathan_f77 9y ago
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.
deleted 9y ago
[deleted]
timendum 9y ago
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
kuschku 9y ago
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 9y ago
  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.
carapace 9y ago
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.
WalterBright 9y ago
> 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.
DrMoisheP 9y ago
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!
kencausey 9y ago
MuPDF seems to be unaffected.

109 points by hannob 9y ago

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

kalleboo 9y ago
Well you could imagine someone uploading a ton of files with this bug to some service that generates thumbnails of PDFs files and overwhelms it
willvarfar 9y ago
And potentially a DOS of web-scrapers that download and try and do anything with them, and a DOS of online services that allow users to upload PDF and do something with them. Does your mail client show a thumbnail preview of PDF docs you receive? Will your mail client get stuck in an endless loop trying to thumbnail a malicious attachment and so on?
yorwba 9y ago
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.

plicense 9y ago

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 9y ago
Wonder why they didn't go for pdf.js, since Chrome already has (had) superior JS performance.
- izacus 9y ago
  Because PDF.js doesn't come close to performance of native C++ code of pdfium (our tests showed 3-10x slowdown).
  - pier25 9y ago
    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.
- gcp 9y ago
  There's a long tail of PDF documents that use obscure PDF features that pdf.js doesn't entirely handle correctly.
- Theodores 9y ago
  They probably don't care. All they needed was that aspect covered so that things like ChromeOS could have the functionality. They went for the guaranteed to work solution rather than reinvent the wheel. Okay, the more developed solution. I do not remember seeing PDF documents when I was last buying Google hardware, my impression is that Google don't see a future in the format, it is mere printer driver to them, not where the party is at.
- deleted 9y ago
  [deleted]
- TazeTSchnitzel 9y ago
  I believe pdf.js is newer than the Chrome PDF viewer.
- SigmundA 9y ago

walterbell 9y ago

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?

Theodores 9y ago
Just do the actual work on a Chromebook, as designed for a 10 year old and complete with rock solid WiFi for £200. Problem solved.
arfar 9y ago
QubesOS has a really nice solution for opening untrusted PDFs: https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-way-safer/ https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-...

Semaphor 9y ago

FWIW, I have no problems with the file in Sumatra. https://www.sumatrapdfreader.org https://www.sumatrapdfreader.org

_pmf_ 9y ago
Very underrated software. Incredible work from a single developer.
- yoodenvranx 9y ago
  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.
- GeekyBear 9y ago
  I agree. It's small (both in file size and system resource usage), fast, and works very well.

_pmf_ 9y ago

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 9y ago
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.

nathan_f77 9y ago

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.

deleted 9y ago

[deleted]

timendum 9y ago

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

kuschku 9y ago

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 9y ago
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.

carapace 9y ago

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.

WalterBright 9y ago

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

DrMoisheP 9y ago

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!

kencausey 9y ago

MuPDF seems to be unaffected.