| Funny, I think I might be one of the worlds foremost experts on PostScript security :) I spent a lot of time researching PostScript interpreter security, and ended up finding a bunch of really interesting bugs. There are of course the regular memory corruption, type confusion, etc, bugs, but PostScript has it's own security model that's intended to stop documents you're printing from interfering with the runtime environment or using internal operators. Those bugs can be fascinating! The TL;DR summary is that PostScript functions are basically just arrays, so to stop documents you're printing from peeking inside and altering system routines, there is a security boundary called "executeonly". The intention is to allow documents to to call routines that might do something powerful on their behalf - e.g. open a printer specification, or run `lpr` or whatever - but not let them open any file or run any command they want. If you could interfere with them, you can break that expectation and get access to root-equivalent operators that let you do whatever you want. Turns out, that's really hard to get right - often you can trick them into faulting and then crawl through the error state to find references to their internals you're not supposed to have! Exploiting these bugs requires some really weird PostScript, here are fun examples: https://www.openwall.com/lists/oss-security/2019/01/23/5
https://bugs.chromium.org/p/project-zero/issues/detail?id=16... I found about a dozen bugs like these while working on it, fun times. |
You could usually exitserver with a default password, then set global state to do annoying things. Imagine every print job being rotated five degrees, or having a weird dead spot somewhere on the page.
I really enjoyed writing postscript. Fun language