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.
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?
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.
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!
> 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.
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.
> 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 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.
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?
[+] [-] plicense|8 years ago|reply
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|8 years ago|reply
[+] [-] Semaphor|8 years ago|reply
https://www.sumatrapdfreader.org
[+] [-] _pmf_|8 years ago|reply
[+] [-] timendum|8 years ago|reply
Also Chromium changes have been merged https://pdfium-review.googlesource.com/c/pdfium/+/12391
[+] [-] walterbell|8 years ago|reply
[+] [-] arfar|8 years ago|reply
[+] [-] Theodores|8 years ago|reply
[+] [-] nathan_f77|8 years ago|reply
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.
[+] [-] DrMoisheP|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] WalterBright|8 years ago|reply
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_|8 years ago|reply
[+] [-] tyingq|8 years ago|reply
[+] [-] carapace|8 years ago|reply
> 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|8 years ago|reply
Anyone have an insight into why evince seems to be so much more often affected?
[+] [-] lower|8 years ago|reply
Both Okular and Evince use poppler for pdf rendering, so they should both get the fix from poppler.
[+] [-] amelius|8 years ago|reply
Probably just denial of your own service, not everybody else's.
[+] [-] yorwba|8 years ago|reply
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.
[+] [-] willvarfar|8 years ago|reply
[+] [-] kalleboo|8 years ago|reply
[+] [-] kencausey|8 years ago|reply