3 ms·
Turing completeness isn’t really a huge problem (and not included in that part of PDF anyway). PostScript in its printer application doesn’t really have I/O exc
by mananaysiempre 3y ago
Turing completeness isn’t really a huge problem (and not included in that part of PDF anyway). PostScript in its printer application doesn’t really have I/O except for, well, the printer, and no raw pointers, so there’s a smaller surface than, say, JavaScript (no network access).
- derefr 3y agoOn its own, the Turing-completeness of PostScript is not a vulnerability, per se. But it does mean that anything that interprets or renders PostScript might take an unbounded (or infinite) amount of time to do so. So PostScript-handling software — even things like virus scanners — have to be coded to handle timing out and interrupting/cancelling PostScript interpretation. (Where PostScript/PDF rendering is often the only format among many "document formats" or "image formats" handled by such software, that imposes this requirement — so when multi-format "reader" software first adds PostScript- or PDF-handling capability, it often finds itself suddenly needing to rearchitect from using single-threaded bounded-time blocking calls to parsers, to needing to use async, concurrency, timers, etc.) That being said, in combination with exploitable vulnerabilities in particular PostScript parsers used in software like Acrobat, the Turing-completeness of PostScript makes it much harder to detect such exploits. 0days in PDF readers are "nice exploits to have", because a PDF virus can be coded such that it's represented in code inside the PDF in an unbounded number of different ways, foiling signature-based virus sanners.
- anthk 3y agoThere's a ZMachine interpreter written in postscript: gs -dNOSAFER zmachine.ps -- yourgame.z3