Converting untrusted PDFs into trusted ones: The Qubes Way (2013)

Re:Converting untrusted PDFs into trusted ones: The Qubes Wa... by trollbridge on Thursday December 12, 2024 @11:28PM (#42405913)

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”.

[ Parent | on HN ]

Re:Converting untrusted PDFs into trusted ones: The Qubes Wa... by Terr_ on Friday December 13, 2024 @12:40AM (#42406203)

> 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.

[ Parent | on HN ]

Re:Converting untrusted PDFs into trusted ones: The Qubes Wa... by SideQuark on Friday December 13, 2024 @01:57AM (#42406481)

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-scrip...

Here’s its JavaScript execution engine for embedding JavaScript in a pdf: 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.

[ Parent | on HN ]