Full Disclosure mailing list archives
Re: vulnerabilities of postscript printers
From: der Mouse <mouse () Rodents Montreal QC CA>
Date: Sat, 24 Jan 2004 12:26:18 -0500 (EST)
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 _______________________________________________ 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)