4

I've read the PDF 1.7 spec 7.11.1 (okay, not all the spec, but a part of it), and I've seen that you have what Adobe calls /Filespec type objects.

As far as I get it, this means that a PDF can make a reference to a local file (or even a remote file using URI scheme) when opening the PDF. This would be a pretty neat way of attacking some servers I'm in charge of, because such server accepts user-uploaded PDF, opens them with wkhtml/tcpdf/jasper to make changes in that PDF, and then resend this PDF to the user. So if the user-uploaded PDF contains a file reference to, say, /dev/random, and if that reference is used as the PDF's page content, then it would open up a breach to read arbitrary server's file content?

I would like to test that, but I can't make such PDF exploit: when opening the PDF I've forged on my lab (ie: not server, just a basic PDF reader), then no content is displayed (and PDF is considered broken).

So do you have some example of such PDF with a working file reference (so I can test if PDF processor is vulnerable to it)? Or any reference stating that these /Filespec cannot be used to read arbitrary file's content (so no need to test the PDF processor)?

Improve this question

1 Answer 1

Reset to default
1

I'm not sure about the feasibility of what you suspect. A library able to work with pdf files may not need to process such Filespec entry to perform its work (for instance the Filespec -if not an embedded file- could be referring to a font, only used when rendering it). And I suspect any library will not enable reading of external files without explicitly enabling such feature, as it could lead -as you note- to nasty surprises.

However, in case of doubt, and given that these are complex programs dealing with a nin-trivial format, I would apply the precautionary principle and process them in a sandbox/chroot/firejail/docker container, so even if the programs processing the pdf could be directed to open arbitrary files they actually can't open any sensitive file, only the standard files that were included inside the sandbox.

Improve this answer
1
  • That's actually why I would like help forging such PDF-to-read-file: to test if the lib does handle them under the hood. Sandboxing could be a mitigation, but that means 1 sandbox must be made per application user, otherwise, user A will upload forged PDF to read files uploaded by user B (while user A should not be allowed to access user B files). Knowing that we also have business rules so user C can allow user A to access some of user C's files, it seems impossible to make up a proper sandbox system (would mean 1 sandbox per user-access combination, I'm not ready to make N^N sandboxes :))
    – Xenos
    Aug 6, 2019 at 8:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .