bugtraq - Re: vulnerabilities of postscript printers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200401230514.AAA05362@Sparkle.Rodents.Montreal.QC.CA>
Date: Thu, 22 Jan 2004 23:15:55 -0500 (EST)
From: der Mouse <mouse@...ents.Montreal.QC.CA>
To: bugtraq@...urityfocus.com
Subject: Re: vulnerabilities of postscript printers

> 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.

PostScript, as a language, is Turing-universal, yes.  If the
implementation permits opening arbitrary communication ports for
read/write, it can be used to copy data around, yes.

It cannot be used for examining memory in the sense that C code or
machine code can.  PostScript as a language does not have notions like
memory addresses or pointers.  (Certainly an implementation could
include a primitive that takes an address and returns the contents of
memory at that address.  But such a thing is unnecessary for normal use
of PostScript, or even for most unusual uses of PostScript, and as far
as I know no implementations have any such.)

> Since the parallel interface is bidirectional what is keeping data
> from being send from the printer to the network, breaching security.

Well, first off, not all parallel interfaces are bidirectional in any
meaningful sense, and least-common-denominator printer interfaces can't
assume that there is any way to communicate anything more complex than
statuses like "printer ready" or "out of paper" in the printer->host
direction.  Thus, they usually won't have hardware support for it.

Second, even if the hardware is bidirectional, the host likely is not
paying any attention to anything coming back from the printer; at most,
it is logging it, fielding errors for reporting to print job
submitters, or perhaps retrieving page counts for accounting.  Finding
a security breach here would mean cracking whatever is listening to
this back-channel.

Third, it would not be easy to usurp control of the printer's CPU to
start with.  PostScript jobs are run in a relatively restricted
virtual-machine environment, and it is difficult for a job to affect
the environment provided for future jobs - generally, it needs to
provide the correct value for a 32-bit "password".  (Such things can be
set insecurely, certainly, but that's no different, really, from having
a Unix box with root's password set to "root": it's admin error.)

Of course, implementation bugs are possible, as with anything.  But
exploiting such a thing isn't using PostScript per se.

> My preliminary web searches do not reveal much in the way of
> postscript printer vulnerabilities.

Well, I have a PostScript printer, and its biggest problem I know of is
that it has, as far as I can tell, no security on whom it will accept
jobs from, so I have to keep it on the non-routable house subnet.  (I
also leave it turned off most of the time.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@...ents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B