3 ms·

PDFs are essentially a representation of PostScript. PostScript itself is expected to be run in a VM and relativepy straightforward to be isolated/sandboxed. S

PDFs are essentially a representation of PostScript. PostScript itself is expected to be run in a VM and relativepy straightforward to be isolated/sandboxed. So there is a certain sense of absurdity of needing to spin up an entire VM just to render a PDF. Running a standard PostScript renderer in a user executable (perhaps in a chroot jail to be a little bit paranoid) should be enough for safety. Or just stick it inside a Docker. Restrict the permissions on the user process to “read my static data files like fonts” and “write output to this 1 file, or a parsing error to this other 1 file”.

Terr_ 2y ago
> PostScript itself is expected to be run in a VM and relativepy straightforward to be isolated/sandboxed. Expected by who? It's been associated with security bugs for decades.
SideQuark 2y ago
PDFs are not simply a representation of postscript. Over the years Adobe has added all sorts of scripting and code execution environments, which are regularly exploited. It supports a lot of image formats, opening yet more attack vectors. It allows plugin integration with every major business app, another wide set of attack surfaces. Here, for example, is but one of the scripting engines https://helpx.adobe.com/acrobat/using/applying-actions-scripts-pdfs.html https://helpx.adobe.com/acrobat/using/applying-actions-scrip... Here’s its JavaScript execution engine for embedding JavaScript in a pdf: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsapiref/index.html https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsa... Your belief is what makes them an excellent exploit deployment format. “What can go wrong? I know tech and they cannot be harmful.” Click.