jamesm@sco.COM (James M. Moore) (01/11/89)
Would having programs (particularly System) check their CODE resources
(and perhaps other types of resources as well) to make sure there aren't
any unknown additions help prevent the spread of the current strain
of viruses?
--
** James Moore **
** Internet: jamesm@sco.com **
** uucp: {decvax!microsoft | uunet | ucbvax!ucscc | amd}!sco!jamesm **
** Nil clu no suim ar bith ag SCO ceard a bhfuil me ag scriobh anois. **cory@gloom.UUCP (Cory Kempf) (01/12/89)
In article <1272@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >Would having programs (particularly System) check their CODE resources >(and perhaps other types of resources as well) to make sure there aren't >any unknown additions help prevent the spread of the current strain >of viruses? Only to the extent that the virus was unaware of the code... A well built virus coud concevebly subvert the software involved in makeing the check to always reporting a negative result (ie no virus), leading to a false sense of security. A better method might be to have any files containing critical resources locked by default, with some non-simulable (is that a word?) way of overriding the lock for legitimate tasks (such as installing fonts, etc. The problems with this are A. How? and B. The system etc. would still be vulnerable at that point. +C -- Cory ( "...Love is like Oxygen..." ) Kempf UUCP: encore.com!gloom!cory "...it's a mistake in the making." -KT
bradn@tekig4.TEK.COM (Bradford Needham) (01/12/89)
In article <1272@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >Would having programs... check their CODE resources >...help prevent the spread of the current strain of viruses? Since all of the known viruses infect applications by adding and modifying CODE resources, this check should detect any such infection of an application. In fact, I recently added such code to my latest project (in Lightspeed C). The code has a table of the program's expected CODE resources and their sizes. On startup, the program compares the size and Resource ID of each available CODE resource against the numbers in the table. Any differences cause a dialog to appear, saying (basically) "This application may be infected by a virus. Here's the CODE resource that looks funny." To make a release of your program, you build it once, see what the CODE resources look like, then update the table of expected CODE resources and rebuild the program. The source code fragment is pretty straightforward, but I can post it if folks are interested. Brad Needham bradn@tekig4.TEK.COM
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/12/89)
In article <3614@tekig4.TEK.COM> bradn@tekig4.TEK.COM (Bradford Needham) writes: >In fact, I recently added such code to my latest project (in Lightspeed C). >The code has a table of the program's expected CODE resources and their >sizes. On startup, the program compares the size and Resource ID of >each available CODE resource against the numbers in the table. Any >differences cause a dialog to appear, saying (basically) "This >application may be infected by a virus. Here's the CODE resource that >looks funny." Suggestions: (o). Compute a checksum also. (just treat the handle as a short **, and sum it.) (o). Use a small tool application to create the data resource, rather than doing it by hand. (o). Allow a "magic number" checksum like, your initials, so you don't need to run the utility each time. (o) Use the same code at run time to see if your application has corrupted itself by a wild store into its own code segment. (I discovered that in color quickdraw, a mal-formed color table can make DrawPicture() scribble on the application heap using this technique.) --- David Phillip Oster --"When we replace the mouse with a pen, Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gasee
chrisj@ut-emx.UUCP (Chris Johnson) (01/13/89)
In article <1272@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >Would having programs... check their CODE resources >...help prevent the spread of the current strain of viruses? Actually, there's already a cdev/INIT designed to protect executable resources (not just CODE resources) from addition/modification/deletion. It also protects the file types of files containing executable resources. All attempts to alter any of these things results in a an entry being written to a log file that'll tell you exactly what ROM call was made, who and what it was directed against, and what application was responsible for the call. The INIT/cdev is called GateKeeper, and version 1.0 was finished and released on January 2nd. It has been posted to comp.binaries.mac and will appear there eventually, but it is already available from Sumex at Stanford and Simtel20 at White Sands. I've tested GateKeeper against Scores and nVIR, against which it has proved totally effective. It should, by the same token, be totally effective against Hpat, and (educated guess only) should be effective against INIT29. GateKeeper was tested prior to its release in several public access Macintosh facilities in which it also proved itself effective and essentially trouble-free. If you can't get it from Sumex or Simtel, I'll be happy to email a copy to you. Hope this helps, ----Chris P.S. The question mark is the on-line help button.
bill@utastro.UUCP (William H. Jefferys) (01/13/89)
In article <9382@ut-emx.UUCP> chrisj@emx.UUCP (Chris Johnson) writes:
#
#The INIT/cdev is called GateKeeper, and version 1.0 was finished and released
#on January 2nd. It has been posted to comp.binaries.mac and will appear
#there eventually, but it is already available from Sumex at Stanford and
#Simtel20 at White Sands.
#
Is GateKeeper intended to be used _instead_ of Vaccine or _in addition_
to it? The documentation doesn't say.
Thanks,
Bill Jefferys
--
Glend. I can call spirits from the vasty deep.
Hot. Why, so can I, or so can any man; But will they come when you
do call for them? -- Henry IV Pt. I, III, i, 53odawa@well.UUCP (Michael Odawa) (01/13/89)
In article <1272@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >Would having programs... check their CODE resources >...help prevent the spread of the current strain of viruses? Yes, the method will work, with certain reservations. This is the same anti-viral technique that the Software Development Council and its regional organizations (SEF, Mass Software Council, Washington Software Assn., etc.) have devised for our members. You should check not only for uninvited CODEs, but also nVIRs and Hpat's and other potentially executeable resources. One reservation is that everyone should use a slightly different coding technique, giving their product a special twist, so that a virus cannot defeat all programs' integrity checks at once. In article <3614@tekig4.TEK.COM> bradn@tekig4.TEK.COM (Bradford Needham) writes: >In fact, I recently added such code to my latest project (in Lightspeed C). >The code has a table of the program's expected CODE resources and their >sizes. On startup, the program compares the size and Resource ID of >each available CODE resource against the numbers in the table. Any >differences cause a dialog to appear, saying (basically) "This >application may be infected by a virus. Here's the CODE resource that >looks funny." This is a great addition to our techniques, and a perfect example of the innovation we are trying to encourage. We also recommend that your program refuse to continue running (i.e., that you ExitToShell() after notifying the user) if its integrity has been compromised. A second reservation is that there are certain viruses in circulation that infect system software but not applications. This technique, when only applied to applications, cannot protect against system viruses. A third reservation is that, since the virus war can be escalated infinitely, it would be theoretically possible to devise a virus that didn't detectably alter executeable resources. However, creating such a virus would be very difficult. To do so would take not only programming skills, but a very malicious motivation. People of that bent belong in jail. Michael Odawa President, Software Development Council odawa@well.uucp
peirce@claris.com (Michael Peirce) (01/14/89)
In article <10330@well.UUCP> odawa@well.UUCP (Michael Odawa) writes: > >We also recommend that your program refuse to continue running (i.e., that >you ExitToShell() after notifying the user) if its integrity has been >compromised. > >Michael Odawa >President, Software Development Council >odawa@well.uucp First off, I want to say what a good job Michael and the Software Development Council are doing getting developers motivated to do something about the virus problems; and I agreee with most of what he says... But, I do disagree with the above statement. Users shouldn't normally continue using virus infected software until things are cleaned up, but there are times when it makes sense for a user to "continue at his own risk". Imagine you're preparing an important report/presentation/article/etc. when an hour before your deadline your software informs you that it refuses to continue. I know that in this position I'd rather take my chances continuing to try to complete my current work, THEN deal with the virus problem. So my $.02: Do the consistency checking. If there's a problem strongly warn the user against proceeding, but do allow it. Otherwise I imagine you'll be getting irate customers complaining about the above scenario. -- michael [Normal disclaimers apply] Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 440 Clyde Avenue | Mountain View, CA 94043 | (415) 960-4011 | MCI-Mail: mpeirce | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}claris!peirce
jamesm@sco.COM (James M. Moore) (01/14/89)
In article <313@gloom.UUCP> cory@gloom.UUCP (Cory Kempf) writes: >Only to the extent that the virus was unaware of the code... A well >built virus coud concevebly subvert the software involved in makeing >the check to always reporting a negative result (ie no virus), leading >to a false sense of security. Yes, but this means that viruses would need to be specific to a certain program. The most likely target would be the system itself, with perhaps special cases for individual applications. While that would certainly not eliminate the problem entirely, it would at least limit the spread of the virus and hopefully make it easier to detect. -- ** James Moore ** ** Internet: jamesm@sco.com ** ** uucp: {decvax!microsoft | uunet | ucbvax!ucscc | amd}!sco!jamesm ** ** Nil clu no suim ar bith ag SCO ceard a bhfuil me ag scriobh anois. **
chrisj@ut-emx.UUCP (Chris Johnson) (01/14/89)
In article <3530@utastro.UUCP> bill@astro.UUCP (William H. Jefferys) writes: <In article <9382@ut-emx.UUCP> chrisj@emx.UUCP (Chris Johnson) writes: <# <#The INIT/cdev is called GateKeeper, and version 1.0 was finished and released <#on January 2nd. It has been posted to comp.binaries.mac and will appear <#there eventually, but it is already available from Sumex at Stanford and <#Simtel20 at White Sands. <# <Is GateKeeper intended to be used _instead_ of Vaccine or _in addition_ <to it? The documentation doesn't say. I recommend using GateKeeper _instead_ of Vaccine. Although I don't know the *exact* nature of the protection afforded by Vaccine, I believe that GateKeeper provides more, i.e. it has a wider and more flexible definition of what constitutes virus-like behavior. I don't believe there's any actual conflict between GateKeeper and Vaccine if they are run on the same system, but running Vaccine tends to cancel out much of the flexibility and transparency I built into GateKeeper, so I don't think that running them both is of much use. My apologies for not dealing with this subject in the on-line help, but I failed to anticipate that anyone would want to run both of them and I didn't want it to seem as though I was out-to-get Vaccine. <Thanks, < <Bill Jefferys No problem, ----Chris
odawa@well.UUCP (Michael Odawa) (01/15/89)
In article <8048@claris.com> peirce@claris.com (Michael Peirce) writes: >In article <10330@well.UUCP> odawa@well.UUCP (Michael Odawa) writes: >> >>We also recommend that your program refuse to continue running (i.e., that >>you ExitToShell() after notifying the user) if its integrity has been >>compromised. >Users shouldn't normally continue using virus infected software...but there >are times when it makes sense...to "continue at his own risk". >If there's a problem strongly warn the user against proceeding, but do >allow it. Otherwise...you'll be getting irate customers. If your warning is worded properly their irritation will be directed right where it belongs, at the low-life who released the virus. Even in the example Mr. Peirce (a fine programmer and great virus fighter, by the way) gave, the infection of a product producing a report just before its deadline, there are other less destructive alternatives than continuing the epidemic. These might include cleaning up the problem with Repair or a similar fixer, using a different computer, etc. Why would you want people using your product, when you know it's been damaged in indeterminate ways? What if the virus is one which wipes out the hard disk? How would the user be in a position to make an intelligent decision? Even with a warning, you'd be flirting with product liability lawsuits if you allowed the user to continue. Seems to me, if you can't guarantee the integrity of your product, you shouldn't let it run. Michael Odawa Software Development Council odawa@well.UUCP
sas1@tank.uchicago.edu (stuart austin schmukler) (01/16/89)
People: I'd like to suggest that all code resources include a signature in addition for the checksum. With this signature we can trace the bugs that creep into the hodge-podge systems we are growing basied on XCMDS and the like. SaS
jamesm@sco.COM (James M. Moore) (01/17/89)
In article <10330@well.UUCP> odawa@well.UUCP (Michael Odawa) writes: >We also recommend that your program refuse to continue running (i.e., that >you ExitToShell() after notifying the user) if its integrity has been >compromised. It would probably be better to give the user the choice. Some people like to modify code on their own, and this would remove that possibility. A dialog box that says something like "The code of this program has been modified in some way. If you didn't do it, or you aren't sure what this means, you've got a problem and should reload your software. If you know what you're doing, feel free to press the OK button..." -- ** James Moore ** ** Internet: jamesm@sco.com ** ** uucp: {decvax!microsoft | uunet | ucbvax!ucscc | amd}!sco!jamesm ** ** Nil clu no suim ar bith ag SCO ceard a bhfuil me ag scriobh anois. **