lan@bucsf.bu.edu (Larry Nathanson) (03/05/91)
JHSangster@DOCKMASTER.NCSC.MIL writes: >I agree with Bob Bosen that signature checking is the ONLY anti-viral >protection that will detect future viruses as well as known ones. My >"preferred implementation", however, is to put the checking in the BIOS >ROM so that any executable can be checked while it is being loaded. >With the checker in ROM, I don't think it is "too easy to fake the all >clear signal" as Bob says. Putting the signatures of the executables into the ROM, is very impracticable. The 'good' information changes almost daily. If the ROM contains every software package, I'm sure that you would need a new chip every week, to keep up with the new revisions. If the ROM contains a personalized version, then you need someone to burn custom ROMs for you. This would still need to be updated on a fairly short term basis. Also, not "concerned user" (tm) has the knowledge/skills to install a ROM. That's probably a $75 service call. Also, what if your friend brings over a new program? Do we have to burn it's checksum into the ROM first? *IF: we just put major software packages used on the machine in the ROM, and ignore the little used ones, we could still wind up with a virus "subpopulation" only in the non-checked software. *IF: we put every package into the ROM, the number of updates required would be ungodly. Every last patch and bug fix would mean a new chip burn. *IF: we use software that changes itself (to reflect user preferences, for example) we need a new burn every time we change a default. Writing a virus that gives the same checksum for every infected and uninfected program is impossible, but it may be possible to write a virus that infects just one package, and keeps the checksum intact. Now this assumes that the virus writer knows what scheme is being used to calculate the signature. The countermeasure to this is to use multiple checksum schemes. Thus while one might show a false "OK", another might catch the change. Caveat: the only unique "number" that represents a given program ONLY, is the program itself. A checksum is a smaller number, that is thought to reasonably uniquely identify it. For example, Wordperfect 4.2 is really just a number that contains ~432,000 digits (assuming file size 432K - I have no idea of the real size.) We are trying to semi-intellegently reduce those digits to around 4-8 that will uniquely identify those 432 thousand. Obviously, if we could get 4 or 8, or even 100 digits that do so, we'd have the most incredible compression system in the world. I'll let the mathematicians out there chew on this one for a while - the feasability of number-crunching the finite viral code into the finite program code to yeild the same checksum. >What is probably needed to get the manufacturers to go along is either >Federal legislation forcing every commercial software vendor to provide >a signature or else a Federal standard requiring it on all software >bought by the Federal government. Or maybe if MicroSoft, AMI, Phoenix >Technologies, IBM, and RSA Data Systems all got together and offered it >as an option for people who wanted it... Unfortunately, we have here an >example of what I like to call the "Railroad Problem" (literary >reference, Heinlein's "Door Into Summer"): If there are no tracks, who >wants to spend money to develop locomotives, but if there are no >locomotives, who wants to spend money to lay down tracks? Whoa!!! Why do the vendors need to provide the signature? You have to have the algorithm to produce the run-time checksum.. Why not just run it on the LOCKED software disk, when you receive it. Those that want the option, can do so. I fail to see how making the company perform some simple computation before shipping the package, versus you doing so after receiving it would accomplish. >And in the >present case, there may well be software vendors who don't like the idea >that someone can prove their negligence if an employee sneaks a virus >into their shipped products. That's why legislation may be necessary. Most reputable software vendors compile the source onto a master disk which is NEVER executed in a machine. It is copied exactly as it is compiled. Thus any resultant virus HAS to be in the source code. If so, there's no hiding from it. Most of the "virus in the shrink-wrapped package" stories I've heard resulted from either 1) the company not following this rule, or 2) the computer store opening and using the package, then re-shrinkwrapping it. Federal virus legislation would severely discourage software companies from coming out with minor releases (read: bug fixes). If they had to file 500 government forms to release the software, they'd just wait for the next major revision before fixing the small problems. "Federal Legislation" is not a panacea. It would add red tape, and loads of beurocracy to a system that is 99% honest and reliable. - --Larry Nathanson // Larry Nathanson . 726 Comm Av #5J . Boston, MA 02215 . 617 266 7419 \\ I've heard they just built a tunnel from England to France. The French drive on the right hand side, the English on the left. Can they save money by building only one lane?