Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!sei.cmu.edu!krvw From: Leichter-Jerry@CS.YALE.EDU Newsgroups: comp.virus Subject: Re: Universal virus detector Message-ID: <0001.9002011922.AA24486@ge.sei.cmu.edu> Date: 31 Jan 90 18:13:00 GMT Sender: Virus Discussion List Lines: 45 Approved: krvw@sei.cmu.edu David Chess asks how my hardware timestamp forms a universal virus detector. He misses the point of my message. I wasn't trying to define a good user interface to such a system; I was only sketching out how the hardware might work. Any creation or modification of executable code on a system is either desired or undesired. You first of all have to be able to distinguish between those two possibilities. The distinction is based on the intent of the operator, so is not amenable to mathematical argument as such. While it may sometimes be difficult to decide exactly what catagory some transitions fall into, in many cases I can be definitive. In particular, there it is almost always the case that no existing executable should be modified, ever. All my existing executables can be checked by comparing their timestamps with known-correct values. Think of this as a very cheap, absolutely unforgeable checksum. More generally, any time I am certain my system is "clean" I can generate and save on a secure medium a list of all timestamps on my disk. Any time later, I can generate a new list and compare. It is then up to me to decide whether any differences that show up are legitimate - but I have the absolute assurance that I WILL get an indication of any changes. BTW, if you really want to build such hardware you can easily go further, in several ways. For example, you can add a hardware-enforced switch which when in the OFF position makes it impossible to set the "is executable" bit at all. In this mode, you can't do program development, install new executables, or even copy executable files - but you absolutely can't be infected either. The vast majority of systems could probably spend most of their time with the switch in this position. Another alternative is to add another bit, the "may create executables" bit. Only code running from a block marked with this bit may turn on the "executable" bit for another block. Normally, only the linker and an image copier would have this bit set. A virus could still be written - but it couldn't modify existing code directly, it would have to produce object code and pass it through the linker. There are certainly some fundamental issues in dealing with viruses, but most of the PRACTICAL issues are the direct result of PRACTICAL hardware and software design decisions. -- Jerry