Onderwerp: vulnerabilities of postscript printers

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.

Thanks
Bob

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

Darren

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

Darren

> 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@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

> 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@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

In some mail from Elizabeth Zwicky, sie said:
>
> > 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.
>
> Sure there is. PostScript has all the standard file handling, among
> other things for handling peripherals for font storage.
[...]
> >Of course if you had a postscript printer AND a the postscript cookbooks
> >you'd instantly get a better understanding.
>
> Umm, apparently not. Although the PostScript manuals are handy, you
> need to dig pretty deep into them to get to relatively little-used
> commands.

Mea culpa.

I'd always believed font handling was just done "special"

Both the "Red book" and "Blue book" are available online and to my
surprise there is "open", "read", "write" and "close". A quick skip
through to the command index shows they're there.

Btw, someone else mentioned something to the effect that hard drives
were "new" to printers. Hard drives have been in printers for ~10 years
(if not more) where you needed 100MB or so of space to spool print jobs.

Darren

In some mail from Elizabeth Zwicky, sie said:
>
> > 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.
>
> Sure there is. PostScript has all the standard file handling, among
> other things for handling peripherals for font storage.
[...]
> >Of course if you had a postscript printer AND a the postscript cookbooks
> >you'd instantly get a better understanding.
>
> Umm, apparently not. Although the PostScript manuals are handy, you
> need to dig pretty deep into them to get to relatively little-used
> commands.

Mea culpa.

I'd always believed font handling was just done "special"

Both the "Red book" and "Blue book" are available online and to my
surprise there is "open", "read", "write" and "close". A quick skip
through to the command index shows they're there.

Btw, someone else mentioned something to the effect that hard drives
were "new" to printers. Hard drives have been in printers for ~10 years
(if not more) where you needed 100MB or so of space to spool print jobs.

Darren

On Thu, 22 Jan 2004, Bob Kryger wrote:

> 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.
>
> Thanks
> Bob
>
>
You may want to look at
http://members.cox.net/ltlw0lf/printers/printers.pdf
by Dennis Mattison.
(I ran across it once, somewhat interesting. Below are my recollections of
what was in it; though admittedly its been about 6 months since I read it.)

I do not believe it addressed any vulnerabilities due to the power of the
Postscript language. I am not well versed in Postscript language, but
am inclined to believe that this is limited.

However, the vulnerabilities in the printer OS are addressed in the above
paper, as well as some nasty stuff that can be done via PCL and related
languages (again, I don't recall any PS specific exploits). The threats
did not really bother me from a practical matter (from the principal of the
lowest hanging fruit, I have quite a few issues which are much more exploitable
).

However, it sounds like you have a much more stringent security posture, and
some of the issues in the paper (and while I did not confirm, the author
seemed to know what he was talking about and the conclusions did not seem
unreasonable). In particular, he claims that several printer vendors have
backdoors in the printers with no password protection, and other blatant
security holes that would be completely unacceptable in just about any other
network device.

There appears to be a significant potential for rewriting the printer embedded
OS, allowing just about anything. Even short of that, there seems to be
potential for using a printer as a presence on your subnet, and presumably in
re to (1), to a more protected subnet if dual hosted. The paper actually
describes several scenarios for "wiretapping" print jobs.

Unfortunately, if I recall correctly, there wasn't a tremendous amount that
one could do about it, other than maybe yell at vendors (which does not do
much for short term). Also, it sounded like HP was one of the more security
conscious vendors.

Tom Payerle
Dept of Physics payerle@physics.umd.edu
University of Maryland (301) 405-6973
College Park, MD 20742-4111 Fax: (301) 314-9525




Tom Payerle
Dept of Physics payerle@physics.umd.edu
University of Maryland (301) 405-6973
College Park, MD 20742-4111 Fax: (301) 314-9525

On Thu, 22 Jan 2004, Bob Kryger wrote:

> 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.
>
> Thanks
> Bob
>
>
You may want to look at
http://members.cox.net/ltlw0lf/printers/printers.pdf
by Dennis Mattison.
(I ran across it once, somewhat interesting. Below are my recollections of
what was in it; though admittedly its been about 6 months since I read it.)

I do not believe it addressed any vulnerabilities due to the power of the
Postscript language. I am not well versed in Postscript language, but
am inclined to believe that this is limited.

However, the vulnerabilities in the printer OS are addressed in the above
paper, as well as some nasty stuff that can be done via PCL and related
languages (again, I don't recall any PS specific exploits). The threats
did not really bother me from a practical matter (from the principal of the
lowest hanging fruit, I have quite a few issues which are much more exploitable
).

However, it sounds like you have a much more stringent security posture, and
some of the issues in the paper (and while I did not confirm, the author
seemed to know what he was talking about and the conclusions did not seem
unreasonable). In particular, he claims that several printer vendors have
backdoors in the printers with no password protection, and other blatant
security holes that would be completely unacceptable in just about any other
network device.

There appears to be a significant potential for rewriting the printer embedded
OS, allowing just about anything. Even short of that, there seems to be
potential for using a printer as a presence on your subnet, and presumably in
re to (1), to a more protected subnet if dual hosted. The paper actually
describes several scenarios for "wiretapping" print jobs.

Unfortunately, if I recall correctly, there wasn't a tremendous amount that
one could do about it, other than maybe yell at vendors (which does not do
much for short term). Also, it sounded like HP was one of the more security
conscious vendors.

Tom Payerle
Dept of Physics payerle@physics.umd.edu
University of Maryland (301) 405-6973
College Park, MD 20742-4111 Fax: (301) 314-9525




Tom Payerle
Dept of Physics payerle@physics.umd.edu
University of Maryland (301) 405-6973
College Park, MD 20742-4111 Fax: (301) 314-9525

>> [about reading arbitray memory locaition with PostScript]
>> ... such a thing is unnecessary for normal use
> And it is not needed. All print jobs come in as PostScript-readable
> files (program plus data) and the software on the printer which reads
> and processes it is PostScript on the surface too,

Well...sort of. The mechanisms that reinitialize printer state between
jobs may be written in PostScript, but they also may not; at least some
of the machinery in question is either not in PostScript or uses
implementation-specific primitives, such as when to stop listening to
just the communication channel handling the current job and return to
listening for a job to arrive on any channel.

> hence at least data-stealing does not need reading or writing of
> arbitrary port or memory locations.

Well, data-stealing does necessarily involve sending the data somewhere
unexpected. This means writing to somewhere more or less arbitrary.

> Especially as the default setup is probably with the "password" == 0
> after each powerloss.

If a printer resets its password to 0 on powerup, yes, that would be a
severe vulnerability. (My printer manages to remember a whole bunch of
other things across power-downs - its IP address, its preferred
language, its lifetime page count, etc - and I see no reason why it
couldn't remember its security password as well, though I haven't
specifically tested that.)

>> Of course, implementation bugs are possible, as with anything. But
>> exploiting such a thing isn't using PostScript per se.
> Come on, der Mouse, according to this logic every Linux exploit which
> is discussed in Bugtraq is "not Linux per se".

Then I misunderstood; I had thought the idea was to write programs in
PostScript to exploit flaws elsewhere - such as in the software
listening to the back-channel on the host - rather than to attack bugs
in the PostScript implementation itself. A fairer analogy to what I
thought was under discussion is that a Linux exploit written in C is
not an exploit of the implementation of C.

Yes, if you are talking about something like a bug which allows
PostScript code received over (say) LocalTalk to receive jobs over
(say) a parallel port and, in addition to printing them, forward them
out over the LocalTalk connection...then, I think, I agree with you.

> Also you seem to have physical access to the machine. What about a
> printer which is sitting in the copy-room on the third floor and
> running day in and day out?

> Your case and your arguments are indirect proof for the insecurity of
> the PostScript-printer situation.

Insecurity against what threats?

The threat under discussion appears to be that of a maliciously
constructed `print job' arranging to steal copies of later jobs,
sending them somewhere else, for the attacker to peruse, as well as (or
maybe even instead of) printing them. If that were all I had to worry
about, I wouldn't hide my printer from world view; I trust the
mechanisms that insulate each job from the previous more than that. I
hide my printer primarily to protect against people sending print jobs
to it and thereby wasting my paper, toner, and print engine lifetime -
a very different threat.

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

>> [about reading arbitray memory locaition with PostScript]
>> ... such a thing is unnecessary for normal use
> And it is not needed. All print jobs come in as PostScript-readable
> files (program plus data) and the software on the printer which reads
> and processes it is PostScript on the surface too,

Well...sort of. The mechanisms that reinitialize printer state between
jobs may be written in PostScript, but they also may not; at least some
of the machinery in question is either not in PostScript or uses
implementation-specific primitives, such as when to stop listening to
just the communication channel handling the current job and return to
listening for a job to arrive on any channel.

> hence at least data-stealing does not need reading or writing of
> arbitrary port or memory locations.

Well, data-stealing does necessarily involve sending the data somewhere
unexpected. This means writing to somewhere more or less arbitrary.

> Especially as the default setup is probably with the "password" == 0
> after each powerloss.

If a printer resets its password to 0 on powerup, yes, that would be a
severe vulnerability. (My printer manages to remember a whole bunch of
other things across power-downs - its IP address, its preferred
language, its lifetime page count, etc - and I see no reason why it
couldn't remember its security password as well, though I haven't
specifically tested that.)

>> Of course, implementation bugs are possible, as with anything. But
>> exploiting such a thing isn't using PostScript per se.
> Come on, der Mouse, according to this logic every Linux exploit which
> is discussed in Bugtraq is "not Linux per se".

Then I misunderstood; I had thought the idea was to write programs in
PostScript to exploit flaws elsewhere - such as in the software
listening to the back-channel on the host - rather than to attack bugs
in the PostScript implementation itself. A fairer analogy to what I
thought was under discussion is that a Linux exploit written in C is
not an exploit of the implementation of C.

Yes, if you are talking about something like a bug which allows
PostScript code received over (say) LocalTalk to receive jobs over
(say) a parallel port and, in addition to printing them, forward them
out over the LocalTalk connection...then, I think, I agree with you.

> Also you seem to have physical access to the machine. What about a
> printer which is sitting in the copy-room on the third floor and
> running day in and day out?

> Your case and your arguments are indirect proof for the insecurity of
> the PostScript-printer situation.

Insecurity against what threats?

The threat under discussion appears to be that of a maliciously
constructed `print job' arranging to steal copies of later jobs,
sending them somewhere else, for the attacker to peruse, as well as (or
maybe even instead of) printing them. If that were all I had to worry
about, I wouldn't hide my printer from world view; I trust the
mechanisms that insulate each job from the previous more than that. I
hide my printer primarily to protect against people sending print jobs
to it and thereby wasting my paper, toner, and print engine lifetime -
a very different threat.

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

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

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

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

Sure there is. PostScript has all the standard file handling, among
other things for handling peripherals for font storage. Alas, I am
moving at the moment and don't have my PostScript manuals to hand,
but, for instance, I've written code that used PostScript filehandling
in GhostScript to modify files in a user's home directory, and code that
used the hard drive in a printer that had one for font caching. In general,
PostScript printers use PostScript as their underlying OS. It is
quite certainly a full programming language.

>Of course if you had a postscript printer AND a the postscript cookbooks
>you'd instantly get a better understanding.

Umm, apparently not. Although the PostScript manuals are handy, you
need to dig pretty deep into them to get to relatively little-used
commands.

Elizabeth Zwicky
zwicky@greatcircle.com

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

Sure there is. PostScript has all the standard file handling, among
other things for handling peripherals for font storage. Alas, I am
moving at the moment and don't have my PostScript manuals to hand,
but, for instance, I've written code that used PostScript filehandling
in GhostScript to modify files in a user's home directory, and code that
used the hard drive in a printer that had one for font caching. In general,
PostScript printers use PostScript as their underlying OS. It is
quite certainly a full programming language.

>Of course if you had a postscript printer AND a the postscript cookbooks
>you'd instantly get a better understanding.

Umm, apparently not. Although the PostScript manuals are handy, you
need to dig pretty deep into them to get to relatively little-used
commands.

Elizabeth Zwicky
zwicky@greatcircle.com