Re: vulnerabilities of postscript printers
From: Darren Reed (avalon_at_caligula.anu.edu.au)
To: firstname.lastname@example.org (Bob Kryger) 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
> 3. What if one of the interfaces is a JetDirect connected via a parallel
> 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.