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?
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.
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.
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.
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.
Performance is not as a good vs native as others have said but its usually good enough for most users with most PDF's.
In practice what really prevents it from being viable in my experience is print quality. Since it uses canvas to render the PDF and their print solution just prints the canvas images, they dpi is low and the output is noticeably "fuzzy". PDF being primarily for print this really kills it. You have to save as PDF and print using Acrobat to get good quality.
If they ever get their SVG back end working it should solve the print issue, honestly they probably should have started with a SVG back end, this same issue plagues many canvas based libraries.
Interestingly they tried to do a canvas based print api (mozPrintCallback) that went nowhere. IMO browsers need better print abilities (see PrinceXML). But at least SVG is rendered to vector on print in all major browsers.
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?
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.
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)?
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.
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
Good reminder that any kind of file processing needs to be heavily sandboxed.
> 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.
> 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.
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!
31 comments
[ 3.4 ms ] story [ 41.7 ms ] threadProbably just denial of your own service, not everybody else's.
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.
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.
Hopefully Web Assembly will change this.
In practice what really prevents it from being viable in my experience is print quality. Since it uses canvas to render the PDF and their print solution just prints the canvas images, they dpi is low and the output is noticeably "fuzzy". PDF being primarily for print this really kills it. You have to save as PDF and print using Acrobat to get good quality.
If they ever get their SVG back end working it should solve the print issue, honestly they probably should have started with a SVG back end, this same issue plagues many canvas based libraries.
Interestingly they tried to do a canvas based print api (mozPrintCallback) that went nowhere. IMO browsers need better print abilities (see PrinceXML). But at least SVG is rendered to vector on print in all major browsers.
https://www.sumatrapdfreader.org
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
Good reminder that any kind of file processing needs to be heavily sandboxed.
Also Chromium changes have been merged https://pdfium-review.googlesource.com/c/pdfium/+/12391
Anyone have an insight into why evince seems to be so much more often affected?
Both Okular and Evince use poppler for pdf rendering, so they should both get the fix from poppler.
> 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.
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.