Date: Sat, 24 Jan 2004 10:39:11 +0100
From: Michael Zimmermann <zim@...aa.de>
To: der Mouse <mouse@...ents.Montreal.QC.CA>
Cc: full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com
Subject: Re: vulnerabilities of postscript printers


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)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists