vulnerabilities of postscript printers

[Bob Kryger]

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

[Darren Reed]

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

[Darren Reed]

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

[der Mouse]

> 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

[der Mouse]

> 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

[Darren Reed]

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

[Darren Reed]

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

[Thomas M. Payerle]

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

[Thomas M. Payerle]

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

[der Mouse]

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

[der Mouse]

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

[Michael Zimmermann]

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

[Michael Zimmermann]

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

[Elizabeth Zwicky]

> 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

[Elizabeth Zwicky]

> 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

[Michael Zimmermann]

At Freitag, 23. Januar 2004 05:15 der Mouse wrote:
> [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,
hence at least data-stealing does not need reading or writing
of arbitrary port or memory locations.


> [...] not all parallel interfaces are bidirectional in any
> meaningful sense [...]

But the parallel interface of the PostScript printer probably is.
Hence it can be used to get data back to the intruder machine.
Or with the modern network interfaces the data exchange
goes over a normal (bidirectional) tcp/ip connection.


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

Reminding colleagues of possible admin errors is not too
far fetched. Especially as the default setup is probably
with the "password" == 0 after each powerloss. Just stumbling
over the powercord in the evening -- oops, sorry --
pushing it back into the socket while my PC is waiting to
installing my own system-software which mimickes the
normal one. Who would recognize anything for years?


> 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".
And regarding PostScript security it may as well be
more a design bug than an implementation flaw.

Let's not forget, that PostScript is for high-level printers
what Windows is for PCs. Nearly all PS printers run the
Adobe system, don't they? A mono-culture par excellance.


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

In your case the printer is only part of one network, der Mouse.
That is you achieve security by positioning it behind a firewall
(or switch it off alltogether).
But the original question assumed a printer connected to two
different networks. And it was asked, wether one could misuse
the printer to access the other network or steal print-jobs.

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.


Regards
--
Michael Zimmermann (Vegaa Safety and Security for Internet Services)

[Michael Zimmermann]

At Freitag, 23. Januar 2004 05:15 der Mouse wrote:
> [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,
hence at least data-stealing does not need reading or writing
of arbitrary port or memory locations.


> [...] not all parallel interfaces are bidirectional in any
> meaningful sense [...]

But the parallel interface of the PostScript printer probably is.
Hence it can be used to get data back to the intruder machine.
Or with the modern network interfaces the data exchange
goes over a normal (bidirectional) tcp/ip connection.


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

Reminding colleagues of possible admin errors is not too
far fetched. Especially as the default setup is probably
with the "password" == 0 after each powerloss. Just stumbling
over the powercord in the evening -- oops, sorry --
pushing it back into the socket while my PC is waiting to
installing my own system-software which mimickes the
normal one. Who would recognize anything for years?


> 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".
And regarding PostScript security it may as well be
more a design bug than an implementation flaw.

Let's not forget, that PostScript is for high-level printers
what Windows is for PCs. Nearly all PS printers run the
Adobe system, don't they? A mono-culture par excellance.


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

In your case the printer is only part of one network, der Mouse.
That is you achieve security by positioning it behind a firewall
(or switch it off alltogether).
But the original question assumed a printer connected to two
different networks. And it was asked, wether one could misuse
the printer to access the other network or steal print-jobs.

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.


Regards
--
Michael Zimmermann (Vegaa Safety and Security for Internet Services)

[Stephen Samuel]

Darren Reed wrote:
> 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.

Hard drives were available for the first of the Apple postscript
laser printers... In fact it was a standing joke that the
printers had more CPU power than the machines they were serving.

There were also a couple of postscript printers that had sun
workstations in their guts... They allowed telnet logins with
trivial (or no) root passwords.
----

I remember one case where someone had attached his PS printer
to a building wide (apartment) net. Didn't use DHCP so he just
assigned it a random address (that conflicted with available DHCP
allocations).

Somebody from the support group logged in to the printer,
did some investigation on it. The end solution was
to print a message on his printer asking him to call the
support group for help.

--
Stephen Samuel +1(604)876-0426 samuel@bcgreen.com
http://www.bcgreen.com/~samuel/
Powerful committed communication. Transformation touching
the jewel within each person and bringing it to light.

[Stephen Samuel]

Darren Reed wrote:
> 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.

Hard drives were available for the first of the Apple postscript
laser printers... In fact it was a standing joke that the
printers had more CPU power than the machines they were serving.

There were also a couple of postscript printers that had sun
workstations in their guts... They allowed telnet logins with
trivial (or no) root passwords.
----

I remember one case where someone had attached his PS printer
to a building wide (apartment) net. Didn't use DHCP so he just
assigned it a random address (that conflicted with available DHCP
allocations).

Somebody from the support group logged in to the printer,
did some investigation on it. The end solution was
to print a message on his printer asking him to call the
support group for help.

--
Stephen Samuel +1(604)876-0426 samuel@bcgreen.com
http://www.bcgreen.com/~samuel/
Powerful committed communication. Transformation touching
the jewel within each person and bringing it to light.

[Nate Eldredge]

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

[Nate Eldredge]

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

[Michael Zimmermann]

Good morning, der Mouse,

as bugtraq is not letting our postings pass, I cc the full disclosure
list, where this topic happened to start also.

Hope I address you correctly. .o)

At Samstag, 24. Januar 2004 05:38 you wrote:
> > [...] 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.

Correctly, but that's not the point. Any system nowadays has some
sort of BIOS or firmware. And with PostScript that are the infamous
implementation specifics.

a) Those implementation-specific operators can be used by a malicious
program as well - the only barrier between the jobs is the environment
setup by the job-monitor (and protected against overwrite by the 32 bit
integer "password").

b) Chances are, that the printer develeoper have not invented the
wheel from scratch but simply bought an Adobe Interpreter in
source code license to which they added their hardware-stubs
written in C plus assembler. Hence at least their PostScript-interfaces
and -semantics are pretty well known.


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

Or polling the printer which special "print"-jobs which do not print
anything at all and can run without notice (except perhaps for some
data-transmission led blinking).


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

Yes, you are right., I was wrong. Probably pushing a little switch on the
backside or inserting a paper clip into a small hole to initialize the printer to
factory defaults might be needed.

So we are back to password guessing. Der Mouse, if you have set your
printer's password-integer, you are the exception of the rule.


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

This would perhaps be the second level of exploiting. The first level would
be to install my personal "layer" above the interesting operators (including
the implementation dependend ones). That way I could augment or
circumvent or even replace the inbuild job-handling with my own version.
That is like being able to put your own interface layer between
the Linux-processes and the kernel. All the processes - including the
system processes will then call my interfaces, if I choose so.

This is trivial in PostScript, the language is made for such things.
Its an interpreter with dynamic binding.

The second layer (your level of exploiting) would perhaps
require low level changes (changing the eeprom) or even be
impossible (because too much is defined in ROM). Depends
of how accessible the interfaces are using the low-level primitives.
On business printers I would expect the ability to initiate a simple
TCP or Apple talk connection if the printer has such interfaces.
It could then be implemented in the printer that the admin receives
some alarm signal upon errors.


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

Part of the original question was using the printer in two different
network (-segments). And you answer with an example where the
printer is only part of one network.

Obviously this is an insider threat of low risk potential.
But anyway I would not allow a PostScript printer to
serve different user groups (even if a member of the
high risk group watches their printouts every time).


If your printer is that safe, der Mouse, why not open a hole in
your firewall, which allows me (and only me) to access the printer
(and only the printer)? I promise: I will not use your paper or toner.
Just a tunnel fixed-IP to fixed-IP. Would you feel safe?


Season Greetings from Snake to Mouse .o)
--
Ka (Michael Zimmermann)

[Jim Knoble]

--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Circa 2004-01-23 16:01:02 +1100 dixit Darren Reed:

: In some mail from Bob Kryger, sie said:
: > Suppose a postscript printer has multiple interfaces connected to=20
: > different networks, is there a way to leverage PostScript to create a=
=20
: > vulnerability such as.
: >=20
: > 1. Allow an attacker log in to the printer and then gain access to the=
=20
: > other network?
: > 2. Create a postscipt program to send copies of printouts to one of the=
=20
: > interfaces?
: > 3. What if one of the interfaces is a JetDirect connected via a paralle=
l=20
: > port?
: >=20
: > It has been suggested that PostScript is very powerful and can be used=
=20
: > to accomplish a number of general purpose computing tasks including=20
: > copying data from one port to another and examining memory. Since the=
=20
: > parallel interface is bidirectional what is keeping data from being sen=
d=20
: > from the printer to the network, breaching security.
:=20
: 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.

False. Have a look at Adobe's 'PostScript Language Reference, Third
Edition':

http://partners.adobe.com/asn/developer/PDFS/TN/PLRM.pdf

Specifically, in section 3.8, 'File Input and Output'. For example:

3.8.1 Basic File Operators

A PostScript file object represents a file. The file operators take
a file object as an operand to read or write characters. Ignoring
for the moment how a file object comes into existence, the file
operators include the following:

* read reads the next character from an input file.
* write appends a character to an output file.
* readstring, readline, and writestring transfer the contents of
strings to and from files.
* readhexstring and writehexstring read and write binary data
represented in the file by hexadecimal notation.
* token scans characters from an input file according to the
PostScript language syntax rules.
* exec, applied to an input file, causes the PostScript
interpreter to execute a PostScript program from that file.=20

[formatting errors mine]. Keep on reading the PDF for instructions on
how to create a file object....

PostScript Level 3 is powerful and rather generalized stack-based
language. Think ghostscript <http://www.ghostscript.com/> embedded into
a printer, some of which (notably CJKV-language printers with rather
large fontsets) even come complete with hard disk drives. Recall that
the ghostscript interpreter comes with command-line arguments you can
use to make the interpreter "safer"; how much safer is left to those who
prefer to inspect the code.

[...]

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

Many of the "crash the printer" jobs actually overflow the PostScript
stack. =20

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

Doesn't matter. If the interpreter isn't properly locked down, all bets
are off.

--=20
jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491 )
.................................................. ...................
:"The methods now being used to merchandise the political candidate :
: as though he were a deodorant positively guarantee the electorate :
: against ever hearing the truth about anything." --Aldous Huxley :
:................................................. ..................:

--envbJBWh7q8WU6mo
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (OpenBSD)
Comment: See http://www.pobox.com/~jmknoble/keys/ for my public key.

iD8DBQFAEWvkKJ/qqBOBFJERAvyrAKCVFQIHcRAsz3zrO4BFX6NwHtOKnQCfdyJT
lWjQGEk5EjVlmlc/sHB7t9k=
=vsxw
-----END PGP SIGNATURE-----

--envbJBWh7q8WU6mo--

[Michael Zimmermann]

Good morning, der Mouse,

as bugtraq is not letting our postings pass, I cc the full disclosure
list, where this topic happened to start also.

Hope I address you correctly. .o)

At Samstag, 24. Januar 2004 05:38 you wrote:
> > [...] 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.

Correctly, but that's not the point. Any system nowadays has some
sort of BIOS or firmware. And with PostScript that are the infamous
implementation specifics.

a) Those implementation-specific operators can be used by a malicious
program as well - the only barrier between the jobs is the environment
setup by the job-monitor (and protected against overwrite by the 32 bit
integer "password").

b) Chances are, that the printer develeoper have not invented the
wheel from scratch but simply bought an Adobe Interpreter in
source code license to which they added their hardware-stubs
written in C plus assembler. Hence at least their PostScript-interfaces
and -semantics are pretty well known.


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

Or polling the printer which special "print"-jobs which do not print
anything at all and can run without notice (except perhaps for some
data-transmission led blinking).


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

Yes, you are right., I was wrong. Probably pushing a little switch on the
backside or inserting a paper clip into a small hole to initialize the printer to
factory defaults might be needed.

So we are back to password guessing. Der Mouse, if you have set your
printer's password-integer, you are the exception of the rule.


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

This would perhaps be the second level of exploiting. The first level would
be to install my personal "layer" above the interesting operators (including
the implementation dependend ones). That way I could augment or
circumvent or even replace the inbuild job-handling with my own version.
That is like being able to put your own interface layer between
the Linux-processes and the kernel. All the processes - including the
system processes will then call my interfaces, if I choose so.

This is trivial in PostScript, the language is made for such things.
Its an interpreter with dynamic binding.

The second layer (your level of exploiting) would perhaps
require low level changes (changing the eeprom) or even be
impossible (because too much is defined in ROM). Depends
of how accessible the interfaces are using the low-level primitives.
On business printers I would expect the ability to initiate a simple
TCP or Apple talk connection if the printer has such interfaces.
It could then be implemented in the printer that the admin receives
some alarm signal upon errors.


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

Part of the original question was using the printer in two different
network (-segments). And you answer with an example where the
printer is only part of one network.

Obviously this is an insider threat of low risk potential.
But anyway I would not allow a PostScript printer to
serve different user groups (even if a member of the
high risk group watches their printouts every time).


If your printer is that safe, der Mouse, why not open a hole in
your firewall, which allows me (and only me) to access the printer
(and only the printer)? I promise: I will not use your paper or toner.
Just a tunnel fixed-IP to fixed-IP. Would you feel safe?


Season Greetings from Snake to Mouse .o)
--
Ka (Michael Zimmermann)

[Jim Knoble]

--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Circa 2004-01-23 16:01:02 +1100 dixit Darren Reed:

: In some mail from Bob Kryger, sie said:
: > Suppose a postscript printer has multiple interfaces connected to=20
: > different networks, is there a way to leverage PostScript to create a=
=20
: > vulnerability such as.
: >=20
: > 1. Allow an attacker log in to the printer and then gain access to the=
=20
: > other network?
: > 2. Create a postscipt program to send copies of printouts to one of the=
=20
: > interfaces?
: > 3. What if one of the interfaces is a JetDirect connected via a paralle=
l=20
: > port?
: >=20
: > It has been suggested that PostScript is very powerful and can be used=
=20
: > to accomplish a number of general purpose computing tasks including=20
: > copying data from one port to another and examining memory. Since the=
=20
: > parallel interface is bidirectional what is keeping data from being sen=
d=20
: > from the printer to the network, breaching security.
:=20
: 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.

False. Have a look at Adobe's 'PostScript Language Reference, Third
Edition':

http://partners.adobe.com/asn/developer/PDFS/TN/PLRM.pdf

Specifically, in section 3.8, 'File Input and Output'. For example:

3.8.1 Basic File Operators

A PostScript file object represents a file. The file operators take
a file object as an operand to read or write characters. Ignoring
for the moment how a file object comes into existence, the file
operators include the following:

* read reads the next character from an input file.
* write appends a character to an output file.
* readstring, readline, and writestring transfer the contents of
strings to and from files.
* readhexstring and writehexstring read and write binary data
represented in the file by hexadecimal notation.
* token scans characters from an input file according to the
PostScript language syntax rules.
* exec, applied to an input file, causes the PostScript
interpreter to execute a PostScript program from that file.=20

[formatting errors mine]. Keep on reading the PDF for instructions on
how to create a file object....

PostScript Level 3 is powerful and rather generalized stack-based
language. Think ghostscript <http://www.ghostscript.com/> embedded into
a printer, some of which (notably CJKV-language printers with rather
large fontsets) even come complete with hard disk drives. Recall that
the ghostscript interpreter comes with command-line arguments you can
use to make the interpreter "safer"; how much safer is left to those who
prefer to inspect the code.

[...]

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

Many of the "crash the printer" jobs actually overflow the PostScript
stack. =20

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

Doesn't matter. If the interpreter isn't properly locked down, all bets
are off.

--=20
jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491 )
.................................................. ...................
:"The methods now being used to merchandise the political candidate :
: as though he were a deodorant positively guarantee the electorate :
: against ever hearing the truth about anything." --Aldous Huxley :
:................................................. ..................:

--envbJBWh7q8WU6mo
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (OpenBSD)
Comment: See http://www.pobox.com/~jmknoble/keys/ for my public key.

iD8DBQFAEWvkKJ/qqBOBFJERAvyrAKCVFQIHcRAsz3zrO4BFX6NwHtOKnQCfdyJT
lWjQGEk5EjVlmlc/sHB7t9k=
=vsxw
-----END PGP SIGNATURE-----

--envbJBWh7q8WU6mo--

[Glynn Clements]

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

PostScript has the ability to read/write named files, and nothing
prohibits an implementation from making peripheral devices or ports
accessible as named files. E.g. using GhostScript on Linux, the
following trivial PostScript program sends a WAV file (or the first
20kb thereof) to the sound card:

(/dev/dsp) (w) file dup
(foo.wav) (r) file
20000 string readstring pop
writestring flushfile

[The -dSAFER switch disables file access, and should be used when
running gs on "untrusted" PostScript files.]

Hopefully, embedded implementations won't provide access to anything
risky, but the possibility isn't completely out of the question.

--
Glynn Clements <glynn.clements@virgin.net>

[Glynn Clements]

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

PostScript has the ability to read/write named files, and nothing
prohibits an implementation from making peripheral devices or ports
accessible as named files. E.g. using GhostScript on Linux, the
following trivial PostScript program sends a WAV file (or the first
20kb thereof) to the sound card:

(/dev/dsp) (w) file dup
(foo.wav) (r) file
20000 string readstring pop
writestring flushfile

[The -dSAFER switch disables file access, and should be used when
running gs on "untrusted" PostScript files.]

Hopefully, embedded implementations won't provide access to anything
risky, but the possibility isn't completely out of the question.

--
Glynn Clements <glynn.clements@virgin.net>

[der Mouse]

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

Actually, PostScript does have open files; find a Red Book, look up the
"file" operator, and follow the pointers to elsewhere. (Many/most
PostScript-capable devices do not have anything of significance by way
of a filesystem, but that's a different issue entirely.)

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

And if you actually read the Red Book, _you_'d get a better
understanding. In the Second Edition Red Book, for example, you'd want
to read section 3.8, "File Input and Output".

/~\ 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

[der Mouse]

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

Actually, PostScript does have open files; find a Red Book, look up the
"file" operator, and follow the pointers to elsewhere. (Many/most
PostScript-capable devices do not have anything of significance by way
of a filesystem, but that's a different issue entirely.)

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

And if you actually read the Red Book, _you_'d get a better
understanding. In the Second Edition Red Book, for example, you'd want
to read section 3.8, "File Input and Output".

/~\ 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

[der Mouse]

> Good morning, der Mouse,

> Hope I address you correctly. .o)

It will do :). I usually drop the "der" in connected writing, where a
name is called for (as here and below).

> a) Those implementation-specific operators can be used by a malicious
> program as well - the only barrier between the jobs is the
> environment setup by the job-monitor (and protected against overwrite
> by the 32 bit integer "password").

Not necessarily; the operators in question may be in a separate
dictionary of their own, or they may not have names in any dictionary.

Of course, if they _are_ accessible and _do_ work, then there is a
potential problem, yes.

> b) Chances are, that the printer develeoper have not invented the
> wheel from scratch but simply bought an Adobe Interpreter [...]

Yes. The monoculture argument. Do you have reason to think the Adobe
interpreter suffers from this problem?

>> Well, data-stealing does necessarily involve sending the data
>> somewhere unexpected. This means writing to somewhere more or less
>> arbitrary.
> Or polling the printer which special "print"-jobs which do not print
> anything at all and can run without notice (except perhaps for some
> data-transmission led blinking).

Yes - but there is not a whole lot of data storage available on most
printers, so you have to know fairly exactly what you're looking for.
(Which of course you sometimes may.)

>> If a printer resets its password to 0 on powerup, yes, that would be
>> a severe vulnerability. [...]
> Yes, [...] [p]robably pushing a little switch on the backside or
> inserting a paper clip into a small hole to initialize the printer to
> factory defaults might be needed.

Yes. And that (a) requires physical access (which admittedly is not
always implausible) and (b) will reset a lot of other values, such as
IP address and default language, and hence is going to be difficult to
do without being noticed, even on an acessible printer.

> The first level would be to install my personal "layer" above the
> interesting operators (including the implementation dependend ones).
> That way I could augment or circumvent or even replace the inbuild
> job-handling with my own version.

Yes...assuming the main loop _is_ written in PostScript. Assuming that
all the necessary operators have accessible names in some accessible
dictionary. Assuming that the operators in question don't mind being
called from within a job context (it wouldn't surprise me if they did
check, and (say) reset the CPU in that case, on the theory that
indicates a bug).

That's a lot of assumptions. Now, it may be that they are all valid
assumptions for some printers. Do you have reason to think there are
any such? So far I've seen nothing but speculation, and that's
certainly all I have on this point. If those assumptions are valid, I
would call it a fairly serious bug, because of exactly this threat.

As for opening up my own printer to you...I'll address that off-list.

/~\ 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

[der Mouse]

> Good morning, der Mouse,

> Hope I address you correctly. .o)

It will do :). I usually drop the "der" in connected writing, where a
name is called for (as here and below).

> a) Those implementation-specific operators can be used by a malicious
> program as well - the only barrier between the jobs is the
> environment setup by the job-monitor (and protected against overwrite
> by the 32 bit integer "password").

Not necessarily; the operators in question may be in a separate
dictionary of their own, or they may not have names in any dictionary.

Of course, if they _are_ accessible and _do_ work, then there is a
potential problem, yes.

> b) Chances are, that the printer develeoper have not invented the
> wheel from scratch but simply bought an Adobe Interpreter [...]

Yes. The monoculture argument. Do you have reason to think the Adobe
interpreter suffers from this problem?

>> Well, data-stealing does necessarily involve sending the data
>> somewhere unexpected. This means writing to somewhere more or less
>> arbitrary.
> Or polling the printer which special "print"-jobs which do not print
> anything at all and can run without notice (except perhaps for some
> data-transmission led blinking).

Yes - but there is not a whole lot of data storage available on most
printers, so you have to know fairly exactly what you're looking for.
(Which of course you sometimes may.)

>> If a printer resets its password to 0 on powerup, yes, that would be
>> a severe vulnerability. [...]
> Yes, [...] [p]robably pushing a little switch on the backside or
> inserting a paper clip into a small hole to initialize the printer to
> factory defaults might be needed.

Yes. And that (a) requires physical access (which admittedly is not
always implausible) and (b) will reset a lot of other values, such as
IP address and default language, and hence is going to be difficult to
do without being noticed, even on an acessible printer.

> The first level would be to install my personal "layer" above the
> interesting operators (including the implementation dependend ones).
> That way I could augment or circumvent or even replace the inbuild
> job-handling with my own version.

Yes...assuming the main loop _is_ written in PostScript. Assuming that
all the necessary operators have accessible names in some accessible
dictionary. Assuming that the operators in question don't mind being
called from within a job context (it wouldn't surprise me if they did
check, and (say) reset the CPU in that case, on the theory that
indicates a bug).

That's a lot of assumptions. Now, it may be that they are all valid
assumptions for some printers. Do you have reason to think there are
any such? So far I've seen nothing but speculation, and that's
certainly all I have on this point. If those assumptions are valid, I
would call it a fairly serious bug, because of exactly this threat.

As for opening up my own printer to you...I'll address that off-list.

/~\ 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

[Bob Beck]

>>> My god, people attach printers to networks! Postscript is Turing Complete!
>> Blah blah - you can't open files...
> Sure you can, RTFM...

Who cares? if it's a network attached printer there's some sort of
IP stack in there speaking lpr, and some semblance of an operating
system. It's a computer. It has network interfaces, the software is
certainly full of bugs and sucks, like most other software. It's
probably exploitable. Why would you treat this device any differently
than any other network attachable device on your secured network?

Either you allow devices to have connections to both secured and
unsecured networks or you don't. If you think a printer, refrigerator,
jet-direct device, set-top-box, 802.11? stuff, coffee machine, coke
machine, Cell phone, PDA, etc. etc. could never be exploited to talk to
whatever it's talking to, please call me, I have a great opportunity
with a moose milking ranch to get you in on early.

-Bob

[Bob Beck]

>>> My god, people attach printers to networks! Postscript is Turing Complete!
>> Blah blah - you can't open files...
> Sure you can, RTFM...

Who cares? if it's a network attached printer there's some sort of
IP stack in there speaking lpr, and some semblance of an operating
system. It's a computer. It has network interfaces, the software is
certainly full of bugs and sucks, like most other software. It's
probably exploitable. Why would you treat this device any differently
than any other network attachable device on your secured network?

Either you allow devices to have connections to both secured and
unsecured networks or you don't. If you think a printer, refrigerator,
jet-direct device, set-top-box, 802.11? stuff, coffee machine, coke
machine, Cell phone, PDA, etc. etc. could never be exploited to talk to
whatever it's talking to, please call me, I have a great opportunity
with a moose milking ranch to get you in on early.

-Bob

[Theo de Raadt]

> >>> My god, people attach printers to networks! Postscript is Turing Complete!
> >> Blah blah - you can't open files...
> > Sure you can, RTFM...
>
> Who cares? if it's a network attached printer there's some sort of
> IP stack in there speaking lpr, and some semblance of an operating
> system. It's a computer. It has network interfaces, the software is
> certainly full of bugs and sucks, like most other software. It's
> probably exploitable. Why would you treat this device any differently
> than any other network attachable device on your secured network?

I concur.

When is the entire security community going to start realizing that

- statistics keep showing there is approximately 1 bug in ever
50-200 lines of code

- these bugs fall into classes of "programmer error", like
heap object overflow, stack object overflow, range check
failure, input mismanagement, race, ...

- for certain classes, nearly EVERY occurance is exploitable,
for instance, nearly all stack object overflows are exploitable

- I am going to estimate that a typical postscript rom is, what,
2MB of code, probably is generated from about 100,000 lines of
code.. are we getting the picture?

Hence, I assume that if something has not been specifically audited by
a person who is allowed to and capable of "cleaning the code to make
it paranoid" as they audit, that code will have bugs.

What stuns me is that someone would even need to ask the question of
"is a postscript printer secure", and that numerous people would get
lost in the rats nest of discussing what the postscript langauge is
capable of. I would bet that most of the security holes in a printer
would be due to crappy low level bugs.

If I can't read the code to confirm that it is crap, I assume that it
is crap.

And I bet there are people actively exploiting printer firmware..

[Theo de Raadt]

> >>> My god, people attach printers to networks! Postscript is Turing Complete!
> >> Blah blah - you can't open files...
> > Sure you can, RTFM...
>
> Who cares? if it's a network attached printer there's some sort of
> IP stack in there speaking lpr, and some semblance of an operating
> system. It's a computer. It has network interfaces, the software is
> certainly full of bugs and sucks, like most other software. It's
> probably exploitable. Why would you treat this device any differently
> than any other network attachable device on your secured network?

I concur.

When is the entire security community going to start realizing that

- statistics keep showing there is approximately 1 bug in ever
50-200 lines of code

- these bugs fall into classes of "programmer error", like
heap object overflow, stack object overflow, range check
failure, input mismanagement, race, ...

- for certain classes, nearly EVERY occurance is exploitable,
for instance, nearly all stack object overflows are exploitable

- I am going to estimate that a typical postscript rom is, what,
2MB of code, probably is generated from about 100,000 lines of
code.. are we getting the picture?

Hence, I assume that if something has not been specifically audited by
a person who is allowed to and capable of "cleaning the code to make
it paranoid" as they audit, that code will have bugs.

What stuns me is that someone would even need to ask the question of
"is a postscript printer secure", and that numerous people would get
lost in the rats nest of discussing what the postscript langauge is
capable of. I would bet that most of the security holes in a printer
would be due to crappy low level bugs.

If I can't read the code to confirm that it is crap, I assume that it
is crap.

And I bet there are people actively exploiting printer firmware..

[Georg Lutz]

On 2004-01-24, Glynn Clements wrote:
> PostScript has the ability to read/write named files, and nothing
> prohibits an implementation from making peripheral devices or ports
> accessible as named files. E.g. using GhostScript on Linux, the
> following trivial PostScript program sends a WAV file (or the first
> 20kb thereof) to the sound card:
>
> (/dev/dsp) (w) file dup
> (foo.wav) (r) file
> 20000 string readstring pop
> writestring flushfile
>
> [The -dSAFER switch disables file access, and should be used when
> running gs on "untrusted" PostScript files.]
>

Does this mean, that a Postscript-file is not safer than a MS Word
document?

Shouldnt -dSAFER be then the default option? Or breaks this something
else?

--
Georg

[Dragos Ruiu]

On January 24, 2004 01:32 pm, Theo de Raadt wrote:
> And I bet there are people actively exploiting printer firmware..

/me points to FX's work at phenoelit.de

I still like his "please insert 25c" message on the LCD panel.
Network attached printers are good portscanners in practice :-).

cheers,
--dr

--
Top security experts. Cutting edge tools, techniques and information.
Vancouver, Canada April 21-23 2004 http://cansecwest.com
pgpkey http://dragos.com/ kyxpgp

[Nicolas Gregoire]

On Fri, 2004-01-30 at 10:15, Dragos Ruiu wrote:

> Network attached printers are good portscanners in practice :-).

And their poor IP stacks are easy to use for Idle scans, allowing to
hide the real source of packets.

And you could too keep your sploits on their hard-drive, which could be
the only one of the network without an AV monitoring it.

--
Nicolas Gregoire ----- Consultant en Sécurité des Systèmes d'Information
ngregoire@exaprobe.com ------[ ExaProbe ]------ http://www.exaprobe.com/
PGP KeyID:CA61B44F FingerPrint:1CC647FF1A55664BA2D2AFDACA6A21DACA61B4 4F