Re: vulnerabilities of postscript printers

From: der Mouse (mouse_at_Rodents.Montreal.QC.CA)
Date: 01/24/04

  • Next message: Dinesh Nair: "Re: Major hack attack on the U.S. Senate"
    Date: Sat, 24 Jan 2004 12:26:18 -0500 (EST)
    To: Michael Zimmermann <zim@vegaa.de>, full-disclosure@lists.netsys.com, bugtraq@securityfocus.com
    
    

    > 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


  • Next message: Dinesh Nair: "Re: Major hack attack on the U.S. Senate"

    Relevant Pages

    • Re: vulnerabilities of postscript printers
      ... > Good morning, der Mouse, ... I usually drop the "der" in connected writing, ... always implausible) and will reset a lot of other values, ... would call it a fairly serious bug, ...
      (Full-Disclosure)
    • [Full-Disclosure] Re: vulnerabilities of postscript printers
      ... > Good morning, der Mouse, ... I usually drop the "der" in connected writing, ... always implausible) and will reset a lot of other values, ... would call it a fairly serious bug, ...
      (Full-Disclosure)