4 ms·
It's nice that PDF security is getting a bit more attention, but there are a number of things that this approach will trash, for instance, I don't have high hop
by ris 7y ago
It's nice that PDF security is getting a bit more attention, but there are a number of things that this approach will trash, for instance, I don't have high hopes for the accessibility of the resulting PDF. (edit: and needless to say, any software in your pipeline which does full interpretation of an untrusted file will itself become the target for attacks, so this is only a useful tool if it is run in an extremely restricted environment)
I for one have been looking a lot into PDF/A for security. PDF/A is really meant for archival, but as a side effect has disallowed an awful lot of weird PDF features which are a security nightmare and pdf readers tend to implement badly/buggily. PDF/A-1 for example, the strictest level, disallows JPEG2000, TIFF, JavaScript, PostScript, embedded files... (PDF/A-3, FWIW is essentially useless from this angle, because they decided to allow arbitrary embedded files, so a valid PDF/A-3 could have pretty much anything in it).
There now exists a good PDF/A validator (https://verapdf.org/ https://verapdf.org/) which can be used to ensure PDFs conform to the standard, but of course, won't fix them if they're not.
PDF/A has an interesting implementation detail however - compliant PDF readers are supposed to automatically "turn off" non-PDF/A features when they encounter a PDF which declares itself as a particular PDF/A variant (even if it then goes on to attempt to use non-compliant features), which would hopefully prevent dangerous sections from being decoded and avoid exploitation). Another interesting feature of PDF is its appendable nature, which might raise the possibility of being able to "declare" an arbitrary PDF as PDF/A by simply appending an extra section to it, hopefully rendering it less harmful (though possibly at the expense of it appearing to have missing content when rendered).
- heartbeats 7y agoCouldn't you just use a whitelist for the features? If the reader can open a PDF/A-1 file and ignore the bad parts, can't it open a PDF file as PDF/A-1 and remove the bad parts, before saving it again? Then you could use the "re-rendering" technique to extract images: 1. Create a stripped PDF/A-1 file from the original PDF. 2. In a VM, render the two PDF files to two high-resolution image sets. 3. Use some CV algorithm to find the differences. For example, gaussian blur, subtract, threshold, find islands. 4. Use this to come up with areas which use complicated PDF features and/or images. Say this returns that there is an image on page 9 in the rectangle ((17, 338), (400, 300)). 5. Crop out page 9 in rectangle ((17, 338), (400, 300)) from the original PDF. Use some CV algorithm to detect the DPI and whether it's best to encode as JPEG or PNG. Encode it and add to list of images. 6. Add sanitized images back from list, mark PDF/A-1 file with images as PDF/A-2. Of course, you could do this for links or whatever as well. Spit out a list of rectangles and link targets in the PDF, and then put them back in.
- ris 7y agoThere are myriad ways that PDFs could be re-written and re-rendered, but they would all be quite complicated and/or throw away a lot of extremely useful "meta" information (bookmarks, signed sections etc.) and almost certainly make files much bigger. The idea of the "appending" trick would be to mutate the original file as little as possible, but convince the reader to open it in a safer mode.
- jrowley 7y agoThe small issue with the append trick is that is that it assumes the reader application will now respect the new format and not open insecure parts... which might not be fully implemented in all cases and is reader specific. Fully sanitizing the PDF yields better guarantees of security at the cost of lost functionality.
- ris 7y ago> The small issue with the append trick is that is that it assumes the reader application will now respect the new format and not open insecure parts... which might not be fully implemented in all cases and is reader specific. Yes, note my original emphasised use of the term "supposed to". > Fully sanitizing the PDF yields better guarantees of security at the cost of lost functionality. Indeed it's a tradeoff. But if you're willing to throw away the features which this extreme sanitization would trample across and have any ability to design PDF out of your system, you're probably better off not using PDF at all in favour of some straightforward image format.
- heartbeats 7y agoI am not sure whether bookmarks or signed sections are "extremely useful". This has some minor advantages, but it's also a large attack surface. At least in this way, you keep most useful features. As jrowley said, if you trust the reader to sanitize it safely, why not trust it to open normal PDF files safely?
- ris 7y ago
- layer8 7y agoThe trick of retroactively declaring a PDF as PDF/A by appending an incremental update won't work well for signed PDFs, because the PDF reader would recognize the PDF as having been modified since the signature, and when displaying the signed version of the PDF (i.e. removing all incremental updates after the signature) the PDF/A declaration will not be part of it and hence the PDF/A restrictions not be observed by the PDF reader. Put slightly differently: A PDF signature effectively freezes the non-PDF/A nature of a PDF.
- ris 7y agoYes - I think this is only true following https://www.pdfa.org/recently-identified-pdf-digital-signature-vulnerabilities/ https://www.pdfa.org/recently-identified-pdf-digital-signatu...
- layer8 7y agoThose vulnerabilities really have nothing to do with the PDF/A question. PDF signature validators have to check for them regardless of PDF/A, and the issue I raised above is independent of those vulnerabilities.