Full Disclosure mailing list archives
Re: vulnerabilities of postscript printers
From: Michael Zimmermann <zim () vegaa de>
Date: Sat, 24 Jan 2004 10:39:11 +0100
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
Current thread:
- Re: vulnerabilities of postscript printers Michael Zimmermann (Jan 23)
- Re: Re: vulnerabilities of postscript printers Valdis . Kletnieks (Jan 23)
- Re: Re: vulnerabilities of postscript printers Ka (Jan 23)
- RE: Re: vulnerabilities of postscript printers Chris DeVoney (Jan 25)
- Re: Re: vulnerabilities of postscript printers Ka (Jan 23)
- Re: Re: vulnerabilities of postscript printers Darren Reed (Jan 23)
- Re: Re: vulnerabilities of postscript printers Michael Zimmermann (Jan 26)
- <Possible follow-ups>
- Re: vulnerabilities of postscript printers Michael Zimmermann (Jan 24)
- Re: vulnerabilities of postscript printers der Mouse (Jan 24)
- Re: Re: vulnerabilities of postscript printers Valdis . Kletnieks (Jan 23)