woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/05/90)
Recently the topic of a Postscript trojan arose over in comp.virus.
I posted a note that the fix (the password restter program) was available,
and subsequently forwarded Nigels code over to the group. That has
resulted in a prolonged correspondance with one, Zibignew Fiedorowic,
who has asked me a question:
Is there any way to defeat the following fragment of code, or will this
provide a secure vaccine for password resetters using the normal
password setting mechanism.
/statusdict begin
/setpassword {pop pop} bind def
end.
The question really is, after doing this, is there anyway to recover the
original setpassword command short of powercycling the controller, or
causeing a hard reset?
What about adding executeonly to this, so you can't redefine it?
You could redifine it in an upper dictionary, but how would you
recover the original def of setpassword?
I have also, made a modification to my password resetter routine to follow
the idea of Nigels code, to only report the password. In addition, I
have left the print eeprom code in place. I'll be willing to post the
routine (the only thing it realy does diffrent from Nigel's code, is
do a hex dump of the eeprom, and identify the interesting locations.)
I still won't send out the writeeeprom routine without a signed
letter head...
Cheers
Woody Baker
Rt.1 Box I
Manor, Tx. 78653.glenn@heaven.woodside.ca.us (Glenn Reid) (08/06/90)
In article <1463@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >Is there any way to defeat the following fragment of code, or will this >provide a secure vaccine for password resetters using the normal >password setting mechanism. > >/statusdict begin > /setpassword {pop pop} bind def > end. > > >The question really is, after doing this, is there anyway to recover the >original setpassword command short of powercycling the controller, or >causeing a hard reset? This looks surprisingly secure, short of rebooting the printer. You might take your handy dig-through-all-dictionaries loop and send it looking for the object you get by doing a statusdict /setpassword get (it is an operator object), just to see if there are any more copies of it somewhere. If you want to really get crazy, you can find all the array objects and look inside of them, too. It's possible that some procedure has a copy inside the body of the procedure. But my guess is that it's the only copy of the "setpassword" operator. It's even possible that Adobe did that on purpose, in their infinite wisdom, so that people could defeat resets of the password in just this manner. But in any case, it looks pretty good to me, although it's awfully easy to reboot a printer, so there's always that. But if the spooler can make sure that this code gets downloaded before any user job can get to the printer, even rebooting should be pretty secure. Of course, you can always just open the serial port directly, reboot the printer, and change the password. But in the event that someone is malicious enough to do all that, you're going to have a pretty hard time stopping him/her. Redefining "setpassword" should defend against the casual virus that isn't targeting any particular machine or printer, but is simply evil and is being propagated. /Glenn -- Glenn Reid PostScript/NeXT consultant glenn@heaven.woodside.ca.us Independent Software Developer ..{adobe,next}!heaven!glenn 415-851-1785
glenn@heaven.woodside.ca.us (Glenn Reid) (08/06/90)
I just had another thought. Rather than redefining "setpassword" to
simply do "{ pop pop }", it ought to help you out a little bit. How
about this one:
statusdict begin
/setpassword {
initgraphics % make sure graphics state is clean
showpage % in case there's already a page in there
/Helvetica findfont 72 scalefont setfont
72 600 moveto
(Someone is) show
72 500 moveto
(trying to) show
72 400 moveto
(change your) show
72 300 moveto
(password!) show
showpage
} bind def
end
If the spooler can tell which userID downloads a job, you might even
have it report the userID of the one who tried to set the password.
Anyway, fun and games with PostScript...
/Glenn
--
Glenn Reid PostScript/NeXT consultant
glenn@heaven.woodside.ca.us Independent Software Developer
..{adobe,next}!heaven!glenn 415-851-1785