Effectiveness of flattening a PDF to remove malware

Question

I'm currently looking at ways to prevent malicious PDF files at the network boundary. This will include virus scanning - but there are known limitations to that. I see a common approach is to flatten the PDF file using something like:

gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=flattened.pdf raw.pdf 

While this certainly seems to remove the usual suspects from the output of pdfid, that alone does not mean that the associated threats have been eliminated.

Hence:

1. Will this approach eliminate most Flash and Javascript exploits?

2. What threats are likely to persist?

Notes:

As this is intended for bulk scanning, suggestions such as this are not really practical at scale.

Links to authoritative sources would be much appreciated.

Update

The method above removes Flash and Javascript from the PDF. Steffen (see below) highlighted that malware embedded in image files would likely survive. To mitigate this, I am downsampling the images. I've not been able to get a clear answer to whether gs preserves or removes EXIF data, but the downsampling will likely alter the offset of any malware embedded there nullifying its exploitability, and the downsampling should also remove any malware embedded in image data. Hence:

DPI=63

gs -dBATCH -dNOPAUSE -dQUIET -sDEVICE=pdfwrite \
   -dDownsampleColorImages \
   -dColorImageDownsampleType=/Bicubic -dColorImageResolution=${DPI} \
   -dDownsampleGrayImages \
   -dGrayImageDownsampleType=/Bicubic -dGrayImageResolution=${DPI} \
   -dDownsampleMonoImages \
   -dMonoImageDownsampleType=/Bicubic -dMonoImageResolution=${DPI} \
   -sOUTPUTFILE=${TMPPDF} ${SRCFILE}

Answer 1

I think using gs should remove all active content (Javascript) and embedded data (Videos, Flash...). But I'm not sure if using pdfwrite directly on the PDF will really remove all active and embedded content. Thus I suggest that you first convert the PDF to Postscript using gs and then convert the Postscript back to PDF using gs with the pdfwrite backend. Since the Postscript format itself does not support active or embedded content such content should not survive the conversion process. I'm not sure if this will also help against image formats, like exploiting vulnerabilities in libjpeg, libpng or similar. In any case the call to gs itself should be done inside some kind of protected environment (i.e. sandbox or similar) so that such vulnerabilities do not affect the security of the security system itself.

Another option would be to convert the PDF to images and maybe create a new PDF with these images then. This way you could protect against exploiting vulnerabilities in image libraries too, but at the cost of loosing the ability to work with the PDF as text (i.e. search, copy...). If you want the additional protection but need the ability to handle the PDF as text you could run some OCR software afterwards to reconstruct the text from the images.

Answer 2

This got too long for a comment.

There are various degrees of flattening. Converting everything to bitmaps would not be recommended if (e.g.) you want to typeset the PDF and can make PDFs large and unwieldy (perhaps you don't care if the input files are all bulk scans). To PS and back again would be reasonable but note you will lose (e.g.) ability to fill in forms. Moreover, password protected PDFs won't be transmissible and action-protected PDFs will need you to use a PDF renderer that doesn't have Adobe DRM in.

Going either to PS or bitmap (and back) should eliminate both JS and flash vulnerabilities, along with a lot of others (e.g. buffer overflows) in terms of the person ultimately viewing the PDFs.

However, whether you go to bitmap or to PS or whatever, you are merely moving (and conceivably duplicating) the problem here. Whatever vulnerabilities previously existed in your PDF viewer may be avoided (assuming the vulnerability can't survive conversion to bitmap / PS and back), but whatever renders the PDF may be subject to the same (or other) vulnerabilities.

Spinning up a VM merely means that VM may get compromised, which is probably less bad than an arbitrary desktop getting compromised.

The best practical idea I can come up with is to spin up, for every PDF, a Docker container (or similar) which is in an exact known state each time, and provides its output as a PS or bitmap file. Then spin up another docker container (each time) to render the output as PDF. It would require a targeted and sophisticated attack to get through that (not shot-gun infected PDF approaches). Spinning up a docker container is very fast, and gives you a degree of isolation. For good measure, do the lot in a VM.