> 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
