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

[ reply ]