Six year old PDF loop bug affects most major implementations
blog.fuzzing-project.org
blog.fuzzing-project.org
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.
Also Chromium changes have been merged https://pdfium-review.googlesource.com/c/pdfium/+/12391
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.
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.
> 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.
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.
Probably 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.