>> [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 (at) rodents.montreal.qc (dot) ca [email concealed]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[ reply ]