🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.virus
Article #5122

Timestamp virus protection

#5122
From: Prof Arthur I. Larky
Date: Thu, 01 Feb 1990 00:00
56 lines
3064 bytes
Perhaps I'm Missing Something

>Date:    Wed, 31 Jan 90 13:13:00 -0500
>From:    Leichter-Jerry@CS.YALE.EDU
>Subject: Re: Universal virus detector

>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.

  I hope we're not talking about the timestamp that MSDOS puts on
a file.  Any time you want to change one, MSDOS will be glad to do
so for you since that's what Int 21H function 57H does for a living.
If you don't want to write in assembly code, it's only a few lines
in Turbo Pascal.

>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.

But that's what I do for a living: "program development, install new
executables, etc."  Oh, well, one can always retire to something less
challenging such as urban warfare.

>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.

  I translate this to mean "find something other than a PC or a MAC
on which to do your computing."  True, but it doesn't solve the current
problem for most of us.

Art Larky
Professor of Electrical & Computer Engineering
Lehigh University
215 Packard Bldg 19
Bethlehem, PA 18015

For all I know, this may not even be my opinion, let alone Lehigh's.
Technical Details
Message-ID: <0012.9002021158.AA26135@ge.sei.cmu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!tank!cps3xx!netnews.upenn.edu!vax1.cc.lehigh.edu!sei.cmu.edu!krvw

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!tank!cps3xx!netnews.upenn.edu!vax1.cc.lehigh.edu!sei.cmu.edu!krvw
From: AIL0@LEHIGH.BITNET (Prof Arthur I. Larky)
Newsgroups: comp.virus
Subject: Timestamp virus protection
Message-ID: <0012.9002021158.AA26135@ge.sei.cmu.edu>
Date: 1 Feb 90 00:00:00 GMT
Sender: Virus Discussion List <VIRUS-L@IBM1.CC.Lehigh.EDU>
Lines: 56
Approved: krvw@sei.cmu.edu