On Fri, 23 Jan 2004, Darren Reed wrote: > In some mail from Bob Kryger, sie said: > > > > During one of our security reviews the following situation was > > uncovered. What are your thoughts? > > > > Suppose a postscript printer has multiple interfaces connected to > > different networks, is there a way to leverage PostScript to create a > > vulnerability such as. > > > > 1. Allow an attacker log in to the printer and then gain access to the > > other network? > > 2. Create a postscipt program to send copies of printouts to one of the > > interfaces? > > 3. What if one of the interfaces is a JetDirect connected via a parallel > > port? > > > > It has been suggested that PostScript is very powerful and can be used > > to accomplish a number of general purpose computing tasks including > > copying data from one port to another and examining memory. Since the > > parallel interface is bidirectional what is keeping data from being send > > from the printer to the network, breaching security. > > > > My preliminary web searches do not reveal much in the way of postscript > > printer vulnerabilities. > > First, remember that postscript has been designed for rendering images > on a page. It has -no- native networking comands nor ability to talk > to any peripheral. Most often, the 'general purpose' tasks have been > to do things like write a postscript program to calculate pi or things > like that. I've never heard of anyone suggesting you could copy data > from one port to another, if only because there's no such thing as an > open file in postscript. [...] This is false. See Adobe's PostScript Language Reference Manual, available online at http://partners.adobe.com/asn/developer/pdfs/tn/PLRM.pdf . Section 3.8, and 3.8.2 in particular, deals with filesystem access. You can open, read, write, delete, and rename files. They describe this as a standard part of PostScript levels 2 and 3, and available in some level 1 implementations. I think it's mainly intended so that PostScript programs have somewhere they can store persistent data, which could be useful. Now, how a particular PostScript interpreter implements these is another question. Certainly a dumb printer could just implement files as chunks of memory somewhere. However, a printer with a real operating system could very well implement PostScript files via OS files, in which case there is certainly the possibility that you can access files you aren't supposed to. For instance, Ghostscript is a freeware PostScript interpreter that runs on Unix and other systems (commonly used for viewing PS files on-screen and printing them to non-PS printers), and it implements the file access functions in the obvious way; and so you can write a PostScript program that deletes all your files. Ghostscript provides a "safe mode" which supposedly disables these functions, but loopholes have been found in it before now... Furthermore, as printers get bigger and fancier (my department's printer has more disk space, and a faster CPU, than my last computer), I think there's going to be a push to have them use more standard hardware and software. If I were designing a laser printer today, I very well might use something like Linux and Ghostscript for the software. Saves the trouble of writing a network stack and PostScript interpreter for $EMBEDDED_PLATFORM. And on such a device, if the privileges and such weren't all correct (and we've all seen plenty of routers and "appliance" servers with this problem), I might be able to have a PostScript program rewrite /etc/passwd and inetd.conf... I think this is a threat that should definitely not be ignored or underestimated. Printers have a poor security record generally, but it's usually been benign as the worst that could happen was that some joker could waste all your paper and toner, and so people don't think about them as a genuine security threat. But this could certainly change. -- Nate Eldredge nge@cs.hmc.edu
