Re: vulnerabilities of postscript printers

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

  • Next message: Daniel.Capo_at_tco.net.br: "Re: Major hack attack on the U.S. Senate" 
    Date: Fri, 23 Jan 2004 23:38:30 -0500 (EST)
To: Michael Zimmermann <zim@vegaa.de>, bugtraq@securityfocus.com

    >> [about reading arbitray memory locaition with PostScript]
    >> ... such a thing is unnecessary for normal use
    > And it is not needed. 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.

    > 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.

    > 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.)

    >> 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.

    > 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.

    /~\ 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: Daniel.Capo_at_tco.net.br: "Re: Major hack attack on the U.S. Senate"

    Relevant Pages

    • [Full-Disclosure] Re: vulnerabilities of postscript printers
      ... Good morning, der Mouse, ... > jobs may be written in PostScript, but they also may not; ... > a very different threat. ...
      (Full-Disclosure)
    • Re: vulnerabilities of postscript printers
      ... Good morning, der Mouse, ... > jobs may be written in PostScript, but they also may not; ... > a very different threat. ...
      (Bugtraq)
    • Re: vulnerabilities of postscript printers
      ... Good morning, der Mouse, ... > jobs may be written in PostScript, but they also may not; ... > a very different threat. ...
      (Full-Disclosure)
    • Re: vulnerabilities of postscript printers
      ... > including copying data from one port to another and examining memory. ... PostScript, as a language, is Turing-universal, yes. ... > from being send from the printer to the network, breaching security. ... PostScript jobs are run in a relatively restricted ...
      (Bugtraq)
    • Re: Printing problem on LAN
      ... I got additional printer ports for Machine1 via a PCI printer port card which was installed after the setup of the computer. ... The re-boot showed the printers were on-line and presumabably eagerly waiting for some print jobs. ...
      (microsoft.public.windowsxp.print_fax)