Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!sei.cmu.edu!krvw From: RADAI1@HBUNOS.BITNET (Y. Radai) Newsgroups: comp.virus Subject: Re: Signature programs Message-ID: <0002.8912081922.AA21833@ge.sei.cmu.edu> Date: 7 Dec 89 12:33:11 GMT Sender: Virus Discussion List Lines: 89 Approved: krvw@sei.cmu.edu Bob Bosen has posted a couple of articles on "signature" programs (I prefer to call them "checksum" programs). I agree with some of what he has written, but disagree with other portions. In V2 #249 he asks Steve Woronick: > Are you saying you could >write or describe a virus that could infect a program but avoid >detection by an off-line ANSI X9.9-based message authentication code? I don't know what Steve's answer is, but mine is definitely YES, and I say that even though I know very little about the ANSI X9.9 algo- rithm. Bob and many others, particularly those with backgrounds in cryptology, tend to emphasize the *algorithm*: X9.9 or DES or RSA is considered by the experts to be more secure than CRC, and that's all there is to it. What they miss is the fact that what has to ensure security on a computer is not simply an algorithm, but rather a *program* which implements it in a given *operating system*. And even a program based on the most sophisticated checksum algorithm in the world is circumventable if it is not written *very carefully*. Take, for example, the PC checksum programs in the directory or of the Simtel20 archives. They all use a CRC (or in a few cases a more primitive) algorithm. Suppose we choose one of them and replace the CRC algorithm by the ANSI X9.9 algorithm. Will that ensure security? Far from it! For one thing, most of these programs have no provision for checksumming the boot sector. That means that despite the use of a sophisticated algorithm, these programs would be totally ineffective against boot-sector virus- es, and that includes a sizable percentage of existing viruses. Boot-sector checksumming is available in a few of these programs, e.g. it was finally added to the FluShot+ program a few months ago. But to the best of my knowledge this program still does not have partition-record checksumming. And that goes for almost all the other programs in those directories also (Sentry is a welcome exception). But is checksumming the BS and PR all we need to worry about? Defi- nitely not. If we perform the checksumming when memory is infected by a Brain-type virus, even X9.9 won't detect any modification. So now all we have to do is ensure that memory is uninfected when we perform the checksumming (by booting from a clean diskette, etc.). Right? Wrong! There are at least five other loopholes in PC-DOS/ MS-DOS which a virus writer could exploit if the program is not care- fully written, all of which are independent of the checksum algorithm and do not depend on memory being infected. (These have apparently never been used in any actual virus so far.) Exploitation of such loopholes is much more practical (from the point of view of the virus writer) than the checksum-forging methods alluded to by several people in this forum, since they are independent of the checksum program and do not require any calculations (of checksums, polynomials, keys, etc.). True, all of these loopholes can be blocked if the author of the checksum program thinks of them. The trouble is not only that most authors do not, but also that there may be other loopholes which none of us has thought of yet. The conclusion is that even a program based on the most sophistica- ted checksum algorithm in the world cannot be depended on to detect all infections. Whether a given algorithm is secure depends heavily on how it's implemented as a *program* in a particular *system*. If it's relevant, Bob, I would suggest that you raise this issue with the rest of the ANSI working group. There's a small problem, however: I have not publicly specified what these additional, more subtle loopholes are, since I feel it would be quite irresponsible of me to do so. But somewhere around No. 89 on my list of 927 things to do is writing virus simulators to implement all, or at least most, of these loopholes. If Bob or anyone else is willing to send me a PC program which implements X9.9 or any other signature algorithm which he thinks is secure, that would raise the priority of my writing at least one of these simulators, which I could then throw at the program in order to test whether it really is secure. Bob also asks: > Who can say whether >the more sophisticated viruses of the future will attempt to analyze >CRC signatures or target specific products that rely on CRC methods? Since he specifically mentions CRC methods, he is obviously not re- ferring to the types of loopholes to which I alluded above. In V2 #238 I gave arguments against the claim that CRC programs are circum- ventable in practice by checksum-forging methods, provided certain ob- vious precautions are taken. Bob has given no reply to these argu- ments and I don't see how emphasis on *future* viruses affects them (except possibly as concerns the time required for the virus to do its work). While I obviously can't prove it, my personal feeling is that *in practice* a CRC algorithm based on a randomly or personally chosen generator is, and will remain, just as secure as any more sophistica- ted algorithm (if the CRC base and program are kept offline) and pro- bably a lot faster. In any case, the most important thing is the pro- gram, not the algorithm. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET