mweiner@bene.at (Michael Weiner) (07/26/90)
Fridrik Skulason (frisk@rhi.hi.is) wrote: > Well, how are we then supposed to disinfect files ? > Just replacing infected > programs with originals may be preferable, and even > necessary in three or > four cases, where the virus destroys the original > program, but the originals > are not always available. We can use a two-stage approach: 1 Use a signature to determine whether the (known) virus CAN be in an individual file. 2 If the signature is found, verify the presence of the virus by using a range-checksum calulation. Range/Checksum information consists of two parts: Entries that define the location of static code in an infected program and checksumming information that indicates which values have to result from the calculation over the defined range if it is a virus. Granted: It looks complicated - but in my opinion it's the only way to play it safe. As an example, let's assume a 'primitive' post-attach COM-file infector: J|CCCCCCCCCCCCCCCC|VVVVVVVVVVVVVVVVVV I I I I Infection host Virus code I JMP to beginning of virus code Step 1: Signature detection *** J|CCCCCCCCCCCCCCCC|VVVVVVVVVVVVVVVVVV *** Signature found Step 2: Verification using checksum calculations ****************** J|CCCCCCCCCCCCCCCC|VVVVVVVVVVVVVVVVVV ****************** Checksumming range Individual bytes of byte fields can be excepted from the calculation range (for counters, storage areas, DTAs and other non-static portions). E.g.Checksum = 1234ABCDh -->> matches virus entry -->> infection can be assumed -->> no risk when removing Checksum = 61A2DAE1h -->> does not match entry -->> Either: - Imitation - Virus scanner - New derivate = NO AUTOMATIC REMOVAL > Suppose that a virus just overwrites > the first 3 bytes of a .COM > file with a JMP to the virus code > and restores the original code with > the following sequence of instructions. > > MOV BX,100H ; beginning of program > MOV AX,[SI+357] ; location of original data > MOV [BX],AX ; restore first two bytes > MOV AL,[SI+359] ; get third byte > MOV [BX+2],AL ; and restore it > > A disinfection program may check if this code fragment > is indeed present at > a specific location, and if so, the original 3 bytes > can savely be written > back to the beginning of the file. I disagree, because I am convinced we will see viruses that carry routines such as the above as UNUSED DATA in their 'body' to fool detection programs and to cause even more damage. PPS: What about XOR [SI+357],AX twice somewhere else in a yet unknown derivate of the virus :-( > >Perfect agreement with that - but it could even get worse: Imagine > >virus derivates deliberately placing JMPs to killer code within their > >body at the location where a recovery program expects the original > >start of the program. > > As soon as this happened, the virus would probably be > sent to the author of > the anti-virus program, who could then update his > program to deal with the > new virus. After all, new versions of anti-virus > programs get distributed a > lot faster than new virus variants. I hope you are right, but I am not as optimistic as you are. Removal programs have to provide a reasonable amount of safety to their user. Hoping "that SCAN (or whatever) knows anyway" is not enough (at least for my part). This is a loophole we can and should shut. > Anti-virus programs are always changing, and as long > as we have several > popular programs, it is impractical to attack them all > in this way. If a virus-writer reverse-engineered CLEAN... :-( > This is becoming more and more difficult, as the > number of self-modifying, > encrypting viruses increases. It seems this group now > includes four viruses, > Stealth (1260), V-101, Suomi (1008) and Flip. I was > not even able to produce a > 16-byte identification string for the Virus bulletin > in those cases, without > using "don't care" characters. Granted. I think we all agree that algorithmic methods have to be used to identify self-modifying and encrypting viruses. Let's hope for a virus-free future... Waiting for criticism, Michael [sorry for the lenth of this messages...] +------------------------------------------------------------+ I UUCP: mweiner@bene.at I I Internet: mweiner@f23.z2.FIDONET.ORG Voice ++43 1 8232400 I I Michael Weiner -- Ghelengasse 4 -- A-1130 Wien -- Austria I +------------------------------------------------------------+