Onderwerp: vulnerabilities of postscript printers

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)

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)

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.

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.

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/develo...fs/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

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/develo...fs/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

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)

--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/develo...FS/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--

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)

--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/develo...FS/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--

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>

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>

> 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

> 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

> 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