Bugtraq mailing list archives
Re: vulnerabilities of postscript printers
From: Darren Reed <avalon () caligula anu edu au>
Date: Fri, 23 Jan 2004 16:01:02 +1100 (Australia/ACT)
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. Another example might be rather than drawing the graph and telling a printer how to draw it, with postscript, you can write a program that you send to the printer and have it draw it. Next, get whichever printer you are interested in to see what extensions they have by way of postscript comments. If there is going to be any 'connect to peripheral' thing, that's where it will be. Of course if you had a postscript printer AND a the postscript cookbooks you'd instantly get a better understanding. Although for those that remember, Solaris 1 came with an X server that listened on port 2000 where you could connect and send postscript commands, rendering directly on to the background of the screen. All that's not to say that a postscript engine is ever perfect...I'm sure everyone who's had a postscript printer can tell of print jobs that have "crashed the printer". Maybe you can buffer overflow one, but what OS are they running in there? It's not likely to be anything you'll have libraries for and maybe not even a CPU you're familiar with. Darren
Current thread:
- vulnerabilities of postscript printers Bob Kryger (Jan 22)
- Re: vulnerabilities of postscript printers Darren Reed (Jan 23)
- Re: vulnerabilities of postscript printers Jim Knoble (Jan 24)
- Re: vulnerabilities of postscript printers der Mouse (Jan 24)
- Re: vulnerabilities of postscript printers Michael Zimmermann (Jan 24)
- Re: vulnerabilities of postscript printers Elizabeth Zwicky (Jan 24)
- Re: vulnerabilities of postscript printers Darren Reed (Jan 24)
- Re: vulnerabilities of postscript printers Stephen Samuel (Jan 24)
- Re: vulnerabilities of postscript printers Glynn Clements (Jan 24)
- Re: vulnerabilities of postscript printers Nate Eldredge (Jan 24)
- Re: vulnerabilities of postscript printers Darren Reed (Jan 23)
- Re: vulnerabilities of postscript printers der Mouse (Jan 23)
- Re: vulnerabilities of postscript printers Michael Zimmermann (Jan 24)