Six year old PDF loop bug affects most major implementations(blog.fuzzing-project.org)
blog.fuzzing-project.org
Six year old PDF loop bug affects most major implementations
https://blog.fuzzing-project.org/59-Six-year-old-PDF-loop-bug-affects-most-major-implementations.html
31 comments
Very underrated software. Incredible work from a single developer.
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.
I agree. It's small (both in file size and system resource usage), fast, and works very well.
Firefox 57 will contains the pdf.js version with this bug fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1393476
Also Chromium changes have been merged https://pdfium-review.googlesource.com/c/pdfium/+/12391
Also Chromium changes have been merged https://pdfium-review.googlesource.com/c/pdfium/+/12391
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?
QubesOS has a really nice solution for opening untrusted PDFs: https://micahflee.com/2016/07/how-qubes-makes-handling-pdfs-...
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.
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.
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.
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!
[deleted]
> 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.
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.
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.
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.
> 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.
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?
Anyone have an insight into why evince seems to be so much more often affected?
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.
Both Okular and Evince use poppler for pdf rendering, so they should both get the fix from poppler.
MuPDF seems to be unaffected.
> 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.
Probably just denial of your own service, not everybody else's.
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.
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.
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?
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
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.
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.
Wonder why they didn't go for pdf.js, since Chrome already has (had) superior JS performance.
Because PDF.js doesn't come close to performance of native C++ code of pdfium (our tests showed 3-10x slowdown).
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.
Hopefully Web Assembly will change this.
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.
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.
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.
I believe pdf.js is newer than the Chrome PDF viewer.
There's a long tail of PDF documents that use obscure PDF features that pdf.js doesn't entirely handle correctly.
[deleted]
https://www.sumatrapdfreader.org