bugtraq - Re: vulnerabilities of postscript printers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200401241802.NAA23484@Sparkle.Rodents.Montreal.QC.CA>
Date: Sat, 24 Jan 2004 12:26:18 -0500 (EST)
From: der Mouse <mouse@...ents.Montreal.QC.CA>
To: Michael Zimmermann <zim@...aa.de>,
	full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com
Subject: Re: vulnerabilities of postscript printers

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