Message-ID: <200401240011.50668.zim__32412.1075486348$1074966300@vegaa.de>
Date: Sat, 24 Jan 2004 01:47:12 +0100
From: Michael Zimmermann <zim@...aa.de>
To: Darren Reed <avalon@...igula.anu.edu.au>
Cc: bugtraq@...urityfocus.com
Subject: Re: vulnerabilities of postscript printers


At Freitag, 23. Januar 2004 06:01 Darren Reed wrote:
> 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.

This statement is misleading. PostScript allows reading and writing of files
for example, if the printer has a disk installed (and some have -- to store 
jobs, fonts, forms and of course system-software). It should also be noted, 
that a PostScript printer establishes a two-way communication with the 
driver. This stdin and stderr files can be access by the user programm
(i.e. by the print-job transmitted to the printer).
Using a special "print"-driver gives me a user "shell" for an apple
and an egg. Every driver writer for PostScript printer knows that,
it's part of the PostScript bibles (I think, in the third book).

Often the system-level is only a password away (if the administrator
has set it at all, which I doubt). Hence a null password or the factory 
default would be a good guess. And I have seen the only possible
password type to be an <integer>. Brute force at night with an
automatic script running on my PC should not be too difficult.

The network communication is part of the system-level, and this
is usually also partly written in PostScript, but at least accessible
from the PostScript level.

Hence the question is: how secure is the job-environment, the "monitor"
or "print spooler" under which the "normal" print-jobs run. This basic 
software is loaded from the printers eprom and/or disk and/or from the 
computer initializing the printer. Additionally there is often a way to 
change the system dictionary with the correct "system" password 
(depending on the implementation). Add to this the possibility to 
reprogram basic I/O routines via burning a new eeprom, if the printer 
has the ability for eeprom-software-update, and you are part of all
attached networks and not even bound by the PostScript semantics 
(though that is not a great bondage anyway).


Bob Kryger had asked (and my answers are):

> 1. Allow an attacker log in to the printer and then gain 
> access to the other network?

	Login is easy.
	Reaching system level may be more difficult (or also easy).
	Complete access to the other network (with the ability to
	send any packet or sniff the other network) is much work,
	but not impossible. Everything depends on the printer.

> 2. Create a postscipt program to send copies of printouts
> to one of the interfaces?

	Probably the easiest goal of them all.
	Depending on the printer.

> 3. What if one of the interfaces is a JetDirect connected
> via a parallel port?

	I assume it would be no hindrance. But
	the question is, how much filtering is done
	in the JetDirect, wether it allows the printer 
	to initiate a (say tcp-) connection etc.
	Then (and only then) it would act as a 
	one-directional firewall. But then the
	intruder has at least access to the printer
	and it's data and can obtain copies of the 
	print-jobs (after intermediate storage in the
	printers virtual memory or disk and through
	regular polling).


Conclusion:

Security critical networks should not share printers with 
insecure nets - no physical connection should be there.
And a PostScript printer is a possible "tunnel" and 
can even be "owned" - depending on it's hardware
+ software situation.


Greetings
Michael
--
Michael Zimmermann
Vegaa Safety and Security for Internet Services

Powered by blists - more mailing lists