RADAI1@HBUNOS.BITNET (Y. Radai) (11/09/89)
Concerning checksum programs, Paul Kerchen writes: > where does one store these checksums and their keys? If >they are stored on disk, they are vulnerable to attack just like >programs. That is, a virus could infect the program and then update >its checksum, since the key must be somewhere on disk as well (unless >the user enters it every time they compute a checksum--yecch!) and one >must assume that the checksum algorithm is known. Or, >more simply, a virus could simply wipe out all the checksums, >leaving the user to decide which files were infected. Storing the >'sums off line would insure security, but at what cost? Checking >and updating the 'sums with any frequency would become tedious at best. First, let's rule out the possibility of wiping out the checksums. To be successful, a viral attack (as opposed to a Trojan Horse attack) must not be obvious. Such an action would immediately be noticed. That leaves us with the more subtle action of altering checksums. Now there are two types of CSPs (checksum programs), sometimes called "dynamic" and "static", and most of Paul's remarks seem to be based on the assumption that we are using the dynamic type. Dynamic CSPs are resident programs which checksum each program which is execu- ted just before its execution. A well-known example is the checksum feature of FluShot+. Static CSPs are non-resident programs which checksum a list of many files on demand, usually at boot time by vir- tue of being placed in the AUTOEXEC.BAT file. An example is Sentry. Now the dangers described above by Paul are no problem for static- type CSPs. In this case one can keep the CSP, along with the CSB (checksum base) and key (generating polynomial in the case of a CRC), on a write-protected, non-infected bootable diskette, and execute the CSP from that diskette after cold-booting from it. Since the CSP is static, this need be done only once per boot, and the additional in- convenience relative to doing this from the hard disk will be very slight. (In fact, there are even utilities which allow you to specify that the program is to be executed only once a day, once a week, etc. even though the command is in AUTOEXEC.BAT.) But suppose one wants to execute the program from the hard disk any- way. We can still foil the checksum forger by simply requiring the user to supply the key interactively. "Yecch!", says Paul, but he is probably thinking of dynamic checksumming. Again, if one uses static checksumming, the key need be supplied only once per boot at the most. Now let's suppose we're using a dynamic-type CSP and prefer the con- venience of doing everything from the hard disk. Would this really make the checksum and keys vulnerable, as Paul claims? Even if it's true that *theoretically* a virus could find the CSB and key and then alter the former, in practice that seems to me rather unlikely for a variety of reasons: First, if the CSB is stored under a name that is not fixed, how would the virus find it? If it does it by searching all files on the hard disk looking for a certain type of content, then infecting some file and computing its new checksum from the key which it has discovered and updating the CSB, that would take a lot of time. One must remember that any modification in a program which causes it to take much more time than usual is likely to be noticed by the user, causing him to suspect a virus. Secondly, forging checksums would make a lot more sense if there were a single CSP which was used by a majority of the users of a given type of computer. But what good does it do to write a program to forge checksums used by a particular type of CSP when it is use- less on the overwhelming majority of computers? Unless the virus creator is satisfied with attacking a very limited environment, such as a student lab, in which all computers use the same CSP, checksum forging hardly seems worthwhile. This is not to say that there are no dangers to CSPs. But checksum forging is not the main one. On most systems there are CSP-fooling techniques which are not only much faster and independent of the par- ticular CSP, but also easier to write. To give a PC example, suppose the hard disk and RAM are infected by a boot-sector virus which hooks Int 13h in such a way that any attempt to read the boot sector results in reading the sector in which the virus has stored the original boot sector (i.e. it works like the Brain virus except that it infects the hard disk also). If the com- puter is booted from the hard disk, the CSP will be activated only after the virus has installed itself in RAM, hence checksumming the boot sector will not reveal that the boot sector has been modified. This particular trick can be overcome by booting from a clean disk- ette before activating the CSP. But on the PC, at least, there are several other ways of fooling a naively designed CSP which cannot be overcome in this way. Chuck Kichler says things similar to what Paul says above, except that he suggests looking in the program (the CSP) instead of in the CSB. The answers are similar. However, he also suggests using a hardware device. This is not a new idea, and there is at least one commercial implementation of this for PCs, called Disk Defender, con- sisting of a card placed between the disk drive and the controller. It comes with software for dividing the hard disk into two logical drives, one of which is left unprotected for necessary writing, while the other is completely write protected, except when it is necessary to transfer files to it. I agree that this is one of the best types of anti-viral protection. But even if we ignore the tedious installa- tion required (if the disk is not initially empty) and the relatively high price ($240, last I heard), one should not assume that it neces- sarily provides absolute protection; it may still be possible for a virus to infect the normally protected drive during those periods when the protection is removed in order to transfer new files to it. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET