ftdkl@acad3.fai.alaska.edu (LaSota Daniel K) (10/13/90)
In article <9113@milton.u.washington.edu>, bjornl@milton.u.washington.edu (Bjorn Levidow) writes... >HyperCard has been crashing on me lately for no apparant reason, and >I read in the Disinfectant 2.0 on-line manual that there is a HC virus. >Has anybody been infected? Does anybody know what the symptoms are? >What the vector is? How to get rid of it if I have it? Any and all >information will be appreciated. Thanks in advance. > >=============================================================================== >\ Bjorn Levidow | Romance is unreal...it's the essence / >\ Dept. of Psychology | of life, but not the reality of it. / >\ University of Washington | ---Robyn Hitchcock / >\ Seattle, WA 98195 | It's mine! All mine! / >\ bjornl@u.washington.edu | I'm independently thoughtful! / >=============================================================================== > Bjorn, probably not a virus. check your memory setting. check for nasty inits. I have a very stable HyperCard 2.0 sys 6.0.5, multifinder init loaded environment (have not crashed 2.0) But what about this: With one new feature of HyperCard 2.0 (can't Abort) comes a new potential for a menace. If the can't abort feature is set then the person can't stop running scripts by typing command-period. This combined with HyperTalks ability to modify script bodies lends itself to script viruses. In the 1.2 versions of HyperCard the user could always stop any script by pounding on the command-period. Imagine this horror story: A public domain stack with nice features on the outside (like a game or recipe for chocolate chip cookies). When the person opens the stack the can't abort setting is toggled to true. The killer cookie stack then locks the screen goes to the persons home stack and modifies the home stack script. This script also injects a few XCMD's which will be called later. As soon as this is done the script goes back to the cookie stack and the user regains control. Well at this point the victim has a few HyperTalk handlers and Xternals that he didn't bargain for. Maybe the new handler in the home stack checks for the date and will only activate after a few days. Maybe a few weeks. When a critical time is past the script executes as soon as ANY stack is opened by the victim. From there XCMD's could be called to do some real nasty stuff like delete files directories etc. I feel kind of weird writing this thinking that I'm giving some slimy jerk ideas but I know if I can think of them, then slimy jerks would eventually too (or already have.) Ok what to do? Well first off don't do it. Writing such stuff is not very hard and if you can do this you could also write good code. Prevention: Think about where stacks come from. It might be a good idea to isolate a stack called "Lefty's 1001 tips to gaining political power" (Even though the name is greater than 32 char) Calm down: The only HyperCard virus I have heard of was the "Dukakis" virus it basically did the same thing as mentioned above except it did something like : put "Vote for Dukakis" into the message box Stay in touch with the HyperCard community. I kind of view the can't abort ability as a programmers crutch. For most stacks the person should always be in complete control. Maybe this can't abort should be removed? Anyways keep your programmer's switch handy. So what does everyone else think? Dan LaSota ftdkl@acad3.fai.alaska.edu
asm31426@uxa.cso.uiuc.edu (_Honest_Puck_) (10/15/90)
In article <1990Oct12.224133.11471@hayes.ims.alaska.edu> ftdkl@acad3.fai.alaska.edu writes: >With one new feature of HyperCard 2.0 (can't Abort) comes a new potential >for a menace. >If the can't abort feature is set then the person can't stop running scripts >by typing command-period. >This combined with HyperTalks ability to modify script bodies lends itself >to script viruses. I've not seen HC 2, yet, so this may seem a dumb question, but how is the can't abort feature set? Is it done something like "set cantAbort to x"? If so, a trick I used to stop userLevel changes may help here... I got tired of stacks that changed the userLevel so I couldn't see the scripts, so i included the following into my Home stack... on set what1 what2 if what1 is "userLevel" or what2 is "userLevel" then exit set else pass set end set (or something like that ... the script's not sitting in front of me at the moment.) This would catch "set userLevel to x" and "set the userLevel to x" and stop them... Granted this only works if the change is under script control... depending upon how cantAbort is set, this may (or may not) help prevent the viruses you fear. --- Aaron Magill -- asm31426@uxa.cso.uiuc.edu