full-disclosure - 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]

From: ka at khidr.net (Ka)
Subject: Re: vulnerabilities of postscript printers

At Samstag, 24. Januar 2004 02:46 Valdis.Kletnieks@...edu wrote:
> For that matter, if the printer has a disk, and a "printout" from
> the insecure net can get the system password, is it able to scavenge
> data from old jobs off the disk?  Most modern multi-user operating
> systems manage to do this correctly, but there's still the occasional
> screw-up (how many times have we seen "Program XYZ embeds random
> data in files" exposures?)

I don't know. But new jobs (from other users) could be copied to disk easily,
if one has the system password. You would just replace (overlay) system
operators with your own versions, which first duplicate and write the data 
to disk and then call the original (overlayed) operator. The printer would
show identical behaviour -- except for being a little slower. And a special
"print job" of yours will deliver the stored data back ("invisibly" over the 
communication-line, parallel- or usb-cable, not on paper) and cleanup 
your "dump" file again.

If the printer has no disk but a lot of memory, you could do the dump into
virtual memory. At least with short print jobs that should be possible.
And as your retrieval job need not print anything, you may use it
to poll the printer for new "dumps" rather often and in short intervalls.

Henry Spemcer from the university of toronto said:
(http://yarchive.net/risks/postscript_password.html)

<quote>
"The default password as shipped is 0.  Very few printer owners bother
to change this.  The problem is that there is significant incentive
*not* to change it... because the PostScript code from a good many
badly-written but legitimate applications tries password 0 and will fail
if it has been changed!  Typically, all the application uses it for is
to set some parameters back to reasonable defaults -- whether the printer
owner wants it that way or not -- but the code makes no attempt to cope
with the possibility of a non-standard password forbidding such changes."

"Believe it or not, there are people who will defend the idea that you should
leave your printer's password unchanged so that programs can mess with its
parameters however they please."
</quote>

ka