Re: vulnerabilities of postscript printers

[Nate Eldredge <nge () cs hmc edu>]

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