To:	   VIRUS-L@LEHIGH.EDU
Subject:   VIRUS-L Digest V6 #2
--------
VIRUS-L Digest   Tuesday,  5 Jan 1993    Volume 6 : Issue 2

Today's Topics:

Re: A user's view of IBM's antivirus/2 (OS/2)
Re: A user's view of IBM's antivirus/2 (OS/2)
Re: Bugs in Mcafee OS/2 Clean (OS/2)
Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/2)
Re: Viruses in OS/2 HPFS (OS/2)
Re: NEW MPC On the way (PC)
Virus Simulator MtE Suppliment (PC)
TBAV 5.01 (PC)
SUMMARY: FORM virus infection in Germany (PC)
Re: Virus Simulator MtE Available (PC)
Re: VSHIELD, VIRSTOP, ... comparison ? (PC)
Solution to using %VARIABLE% with scan (PC)
Re: Integrity Management (PC)
Re: SVC 6.0 not rem. by F-PROT206a (PC)
Re: Virus Simulator MtE Available (PC)
Chkdsk / undelete fix from Microsoft. (PC)
Clearing out old signatures (PC)
"Beneficial" viruses
Checksums, signatures, and "good enough" algorithms. (Generic)
Definition of computer virus (was FC on virus creation)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
your real name.  Send contributions to VIRUS-L@LEHIGH.EDU.
Information on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list.  A FAQ (Frequently
Asked Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<krvw@CERT.ORG>.

   Ken van Wyk

----------------------------------------------------------------------

Date:    22 Dec 92 12:17:35 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: A user's view of IBM's antivirus/2 (OS/2)

tyetiser@umbc5.umbc.edu (Mr. Tarkan Yetiser) writes:

> DC>> or that their boot record had changed (because they
> DC>> changed a volume serial number).
			^^^^^^^^^^^^^
> >Hey, they should be really power users, if they know how to do that!
> >For instance, I don't know how it can be done, without reformatting
> >the disk, or using a sector editor... And anybody who is competent
> >enough to mess with a sector editor in the boot sector, should not be
> >surprised by a message that the said sector has been modified afterwards...

>    No, it is not really necessary to be a power user. If you use the
> LABEL command with DOS 4.0 or above, it will update the BPB in the
> boot sector.  DOS 4.0+ records the volume label at offset 2Bh in the
> boot sector.

I know that. That's why a boot sector integrity checker should exclude
this area. But David mentioned the volume SERIAL NUMBER, not the
volume label... I didn't know that the serial number can be changed
with the LABEL command... Can't verify it now - I am running DR-DOS -
but I am pretty much convinced that it cannot...

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

------------------------------

Date:    22 Dec 92 12:21:38 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: A user's view of IBM's antivirus/2 (OS/2)

tck@fold.ucsd.edu (Kevin Marcus) writes:

> >Hey, they should be really power users, if they know how to do that!
> >For instance, I don't know how it can be done, without reformatting
> >the disk, or using a sector editor... And anybody who is competent
> >enough to mess with a sector editor in the boot sector, should not be
> >surprised by a message that the said sector has been modified
> >afterwards...

> Well, I don't have the entirety of the original sentence, so I might
> be missing something, but, int 25h will let you read in the boot
> sector, you modify it however, and rewrite it with int 26h.

Yes, of course, but as I said, anybody who is competent enough to do
that (especially if s/he knows the difference between using INT
25h/26h under DOS 4.x+ and the DOS versions below) is a power user and
shouldn't be surprised by a message the the boot sector has been
changed... Besides, it is trivial to make the integrity checker
exclude this area of the DOS boot sector from the integrity check...

> Additionally, I have just recently seen some 486-50s with AMI BIOS's
> (copyright 1992, I dont' know the exact date, though), that allow for
> a "bootsector virus protection".  Which is somewhat funny.  Since I do
> a lot of fdisking and formatting of drives on new systems, they scream
> these messages, "Boot sector write - continue? (Y/n)" type of thing.

Sounds like a very nice feature, unless it is not possible to turn it
off, of course... :-)

> THe funniest thing, however, is that it didn't do that when I ran sys
> on a hard drive.  In fact, they mean bootsector of floppy, or MBR on
> hard drive.  

No, they probably mean track 0, side 0, sector 1 of ANY drive... This
the boot sector on diskettes and the MBR on hard disks.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 22 Dec 92 09:57:19 -0500
From:    Otto Stolz <RZOTTO@NYX.UNI-KONSTANZ.DE>
Subject: Re: Bugs in Mcafee OS/2 Clean (OS/2)

Hello,

on Fri, 18 Dec 92 18:13:10 +0000 Brett J.L. Landry <bjl1@Ra.MsState.Edu>
said:
> OScan discovered that there was stoned in two partitions on 120 meg
> drive

Obviously a canard! On hard-disks, Stoned is a MBR infector, hence it is
*never* in a partition. (There is only one MBR on any one HD, which is
outside of all partitions; rather, it defines the partitions.)

> The problem came into play when I cleaned using OSclean.  It
> removed stoned but also removed the second partition loosing the 80
> meg section.

I do not know OSclean. But if it indeed tried to clean Stoned off
partitions (i.e. OS boot records), anything seems possible...

> Any thoughts on this would be appreciated.

Just my 2 Pennies' worth of thoughts...

Merry Xmas to those who celebrate it, and best wishes to all,
                    Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
                               <RZOTTO@nyx.uni-konstanz.de>

PS. I've sent detailed Stoned info to J.L.Landry, privately.

------------------------------

Date:    22 Dec 92 18:40:09 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/
	  2)

aryeh@mcafee.com (McAfee Associates) writes:

> >Do you know any way in which a known DOS virus can infect an extended
> >filename on an HPFS partition?

> Nope.  But I myself create directories under OS/2 HPFS with names like 
> "MS-DOS 3.3 Files" and "Today's Downloads" in which I keep normal DOS
> files.  I'm sure other people do as well :-)

Yup, you are right. And there is one more possibility, which I figured
out myself after posting my message. A virus could infect a file with
a short filename and the user could rename it later to an extended
filename. If the scanner does not scan those files, then there is a
danger for reinfection.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

------------------------------

Date:    22 Dec 92 18:53:08 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Viruses in OS/2 HPFS (OS/2)

bjl1@Ra.MsState.Edu (Brett J.L. Landry) writes:

> There has been aa lot of talk about OS/2 not being able to be infected
> from regular old DOS boot sector viruses using the HPFS. This is false
> since regular old STONED can infect both logical and physical parttions
> on OS/2 using HPFS.  Why wait for true OS/2 viruses when you can suffer
> from regular DOS viruses.

I don't know what do you call logical and physical partitions on OS/2
using HPFS, but Stoned can infect only one thing - the Master Boot
Record of the hard disk. That is, the sector at track 0, side 0,
sector 1. It can be infected on any IBM PC compatible machine,
regardless whether it runs MS-DOS, OS/2, Unix, or whatever.

Some systems (Unix) may become non-bootable after the infection. On
other systems (OS/2) the virus will be unable to spread further, i.e.
to infect diskettes.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

------------------------------

Date:    Mon, 21 Dec 92 19:48:00 -0500
From:    ncoast!arnold@usenet.INS.CWRU.Edu
Subject: Re: NEW MPC On the way (PC)

JDG111@PSUVM.PSU.EDU writes:
>Rumor has it that a newer verion of the Phalcon/Skism MPC (Mass
>Produced Code Generator) is going to be released sometime soon.  My
>source didn't say when, but "soon".  Also, a new edition of the 40-Hex
>magazine is suposedly coming out around New Years.  Happy New Year
>everyone.  <sigh>

Yes there is a new 40-hex comming out, I am in-contact with a member
and he said issue 9 would be out.  The group for to everyone's releif
disbanded after their big Bust, but unfortunately they banded together
again about a week after the anouncement.  I have also been told that
McAFEE can already detect all the virus created with the MPC.  Note:
There is a new Mutation Engine out called TPE, it E It is from Italy
or Somewhere near in, and supposedly it is better an MTE.  I don't
know I will have to test it but I will post my results..

Arnold

------------------------------

Date:    22 Dec 92 02:24:13 +0000
From:    as194@cleveland.Freenet.Edu (Doren Rosenthal)
Subject: Virus Simulator MtE Suppliment (PC)

 Doren Rosenthal
 Rosenthal Engineering
 3737 Sequoia
 San Luis Obispo, CA USA 93401
 
 November 21, 1992
 
 
      >From: frisk@complex.is (Fridrik Skulason)
      >Subject: Re: Virus Simulator MtE Available (PC)
      >Date: Fri Dec 18 05:15:10 1992
 
      >as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:
 
      >>     are  using  their MtE virus detecting  programs  correctly,
      >>     additionally  affording  an  opportunity  for  a   practice
      >>     training drill under safe and controlled conditions.
 
 >I just hope that everybody realizes that the ability of a program to
 >detect the files generated by the "Virus Simulator" does not at all
 >indicate if it will detect the actual viruses or vice versa, which
 >makes this effort quite pointless, IMHO.
 
 >- -frisk
 
 Frisk,
 
 Thank  you for your comments on my Virus Simulator MtE Supplement. I'll  be 
 mailing  the first copies january 1, so I hope your opinion  is  mistakenly 
 based  on  my original Virus Simulator and not your technical review  of  a 
 program you could not possibly have examined yet. Readers of this forum may 
 recall  the  considerable  controversy and  strong  opinion  you  expressed 
 beginning two weeks before my release of that program as well.
 
 Because of the security nature of the Virus Simulator MtE Supplement, it is 
 only available directly from Rosenthal Engineering and you should not trust 
 it  to  be harmless unless you can directly trace its source  to  Rosenthal 
 Engineering without compromise. The Virus Simulator MtE Supplement is  only 
 available  to  registered users of Virus Simulator, it  is  not  shareware. 
 Registered users of Virus Simulator should be receiving the Virus Simulator 
 MtE Supplement shortly, without additional charge.                
  
 The  Virus  Simulator  MtE  Supplement compiles  a  test  suite  of  highly 
 controlled,  safe test viruses and special dummy programs they will  infect 
 (only).  The test viruses will only infect the special dummy test  programs 
 generated by the Virus Simulator MtE Supplement. Provisions have been taken 
 to  discourage modification and tampering. Both .EXE and .COM  viruses  and 
 dummies  are  provided.  With the exception of  their  special  safety  and 
 security provisions, the MtE test simulations are real polymorphic viruses.  
 
 At  the hart of these MtE virus simulations is an actual Dark  Avenger  MtE 
 mutation engine. The MtE engine provides virus writers with the ability  to 
 turn  their relatively simple programs into very sophisticated  polymorphic 
 viruses  which  are extremely difficult to detect by virus  scanners.  Each 
 time  the  virus infects a host program it mutates, changes  its  signature 
 pattern  to avoid recognition. A few examples of viruses that  employ  this 
 same MtE engine are:
 
 Pogue,  Dame, MtE, Gotcha, 7S, Mut, Dedicated, Fear, Groove,  Coffee  Shop, 
 MtE-Spawn, Questo, Crypto Lab, Encroach. 
 
 Although  the  MtE  simulations  produced  by  my  program  are  safe   and 
 controlled, they are real viruses, capable of infecting their special dummy 
 host  programs. Vigilant anti-virus programs that are capable  of  reliably 
 detecting the MtE mutation engine should report these simulations as  being 
 infected.  Because these are real polymorphic viruses several  samples  are 
 required  to validate a virus detector, as each time the virus  mutates  in 
 attempt to avoid detection, its signature changes. 
 
Doren Rosenthal

------------------------------

Date:    Mon, 21 Dec 92 02:47:00 +0000
From:    Malte_Eppert@f6002.n491.z9.virnet.bad.se (Malte Eppert)
Subject: TBAV 5.01 (PC)

Hello Vesselin,

you wrote about TBCHECK:

 > It doesn't know about PATH companions.

Well, it won't let them through. If you have a validated file called
HELLO.EXE, and a path companion virus creates some HELLO.COM in a
directory listed in the DOS path, and you issue "HELLO" in a path
different from that one where HELLO.  EXE resides in, then TBCHECK
would give a warning like "HELLO.COM is not listed in the
ANTIVIR.DAT-File. Stop execution?". So it takes care of it. Of course
you're right with the other weaknesses (DOS file fragmentation, fixed
polynomial). The product is unfortunately not designed to stand a
directed attack, but it's a nice approach for a multilayer concept, I
think.

BTW: what do you think about the tunneling-stopping features of TBAV?
Do the utilities effectively stop tunneling? They e.g. prevented
TBSCAN from tracing to the BIOS entry point :-)) in version 5.01, and
when I executed the Tequila virus, TBAV said: TEQUILA.EXE tries to
trace to the BIOS entry point and advised me to reboot.

 >> BTW: I managed to have Armageddon infect a file after I allowed the
 >> virus to go TSR, though I've activated the whole product palette.
 >> What's that - a special way to put its code into a file, which TB
 >> doesn't recognize?

 > I'm afraid that I do not understand the question... There's nothing
 > special with Armagedon - it just prepends itself to the COM files -
 > like the Jerusalem virus does...

That's what I thought, too... Well, how does it manage to successfully
infect a file via 'standard methods' when TBAV is active, then? Any
other link virus I tested was stopped (I just have a few ones). For
example, the Cascade triggers the same warning ("This program tries to
remain resident in memory and is not confirmed to be allowed to do
this") as Armageddon, and when I allow it to go TSR, it tries to
infect COM files on execution - but is caught by TBAV. Armageddon is
not, it happily infects any COM file without any interception - why?

cu!
eppi

- --- Via SCANTOSS V 1.37
 * Origin: No Point for viruses - The EpiCentre! (9:491/6002)

------------------------------

Date:    Tue, 22 Dec 92 04:39:41 -0500
From:    David Hanson <cfsc-hga-gc-mis@augsburg-emh1.army.mil>
Subject: SUMMARY: FORM virus infection in Germany (PC)

I wrote:

>On 18 November 1992, we discovered the FORM virus on the boot
>sector of 12 of our PC hard disks.
>Question:  Outside of using a commercial anti-virus package,
>           is there any way of eliminating this virus "manually"
>           (ie. editing sectors on the disk)?


mcafee@netcom.com (McAfee Associates) writes:

>> The DOS SYS command can be used to overwrite the boot sector off
>> infected disks to remove the virus.  Afterwards, run the DOS CHKDSK /F
>> command to recover any clusters marked as bad by the virus (if using
>> DOS 5.00, make sure your disk can have CHKDSK /F run safely on it, or
>> upgrade to MS-DOS 5.00a).

>>Oops, my mistake, CHKDSK recovers lost clusters, not bad
>>ones.

Thanks to all who wrote to tell me to use SYS.COM.  However, I don't
think that I would recommend SYS without the caveat that you may lose
some FAT information.  Areyah alludes to it in his response, and in
reality, there can be quite a bit of destruction.

CHKDSK can be pretty heavy-handed in doing FAT repair, so I would
suggest to anyone attempting to use SYS to remove a FORM infection:
Have your Disk Doctor (or whatever) handy 'cause you're going to need
it!

Again, thanks to all who responded...

David Hanson
cfsc-hga-gc-mis@augsburg-emh1.army.mil

------------------------------

Date:    Tue, 22 Dec 92 11:11:40 +0000
From:    icking@gmd.de (Werner Icking)
Subject: Re: Virus Simulator MtE Available (PC)

as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:
>              Virus Simulator MtE Supplement Available
>          ------------------------------------------------                    
 
> 
>     An  MtE virus simulation test suite generator is  available 
>     suitable   for   use   by   general   end   users,   system 
>     administrators  and  educators. [...]

Where? How to get it? Free/share/beg/charity/.../ware?

- --
Werner Icking        Werner.Icking@gmd.de        (+49 2241) 14-2443     __o
GMD - Gesellschaft fuer Mathematik und Datenverarbeitung mbH          _`\<,_
Schloss Birlinghoven, P.O.Box 1316, D-5205 Sankt Augustin, Germany   (_)/ (_)
                             "Der Dativ ist dem Genitiv sein Tod." ~~~~~~~~~~~

------------------------------

Date:    Tue, 22 Dec 92 07:20:53 -0500
From:    David_Conrad@MTS.cc.Wayne.edu
Subject: Re: VSHIELD, VIRSTOP, ... comparison ? (PC)

In VIRUS-L v5i203 (Vesselin Bontchev) writes:
>mramey@u.washington.edu (Mike Ramey) writes:
>> [requesting] a point-by-point comparison of VSHIELD and
>> VIRSTOP?
>> One of my questions is this: VSHIELD intercepts a keyboard reboot and
>> checks for the presence of an infected diskette in the boot diskette
>> drive;
>
>No, VIRSTOP doesn't have such feature (yet).
>
>2) VShield can scan a file while it is being copied. VirStop does not
>have such a feature yet, although Frisk is promising it since a long
>time.
>

From recent comments Frisk has made here it sounds as though scanning
while copying and scanning diskette boot sectors on access will be in
the next version.  For preventing boots from diskettes (to the extent
it can be done) Padgett's NoFboot and SumFboot programs are excellent
and have served me well.

>3) VShield uses much more memory than VirStop.
>
>4) VShield can be swapped out to the disk, in order to reduce the
>amount of memory used. This slows down the loading of the programs.
>VirStop does not have such an option (although Frisk intends to
>implement it), but then the memory requirements for VirStop are much
>more modest.

This isn't really correct.  The /DISK option to VirStop causes it to
read the signatures from disk instead of loading them into memory, and
reduces the memory requirements from 12K to 2K.  It is true that there
is no way to swap out the 2K kernel, but that would almost be silly.

Otherwise a fine comparison.

Regards,
David R. Conrad
David_Conrad@mts.cc.wayne.edu, dave@michigan.com

------------------------------

Date:    Tue, 22 Dec 92 07:20:55 -0500
From:    David_Conrad@MTS.cc.Wayne.edu
Subject: Solution to using %VARIABLE% with scan (PC)

In VIRUS-L v5i203 (Vesselin Bontchev) writes:
>craig@cadzook.columbiasc.NCR.COM (Craig.Williamson) writes:
>> OK here is what I am trying to do:
>
>> SET NETDRV=x:
>> scan c: d: e: /date/report %NETDRV%\vir_rep
>
>> The %NETDRV% is not getting replaced with x: like it should.
>
>Hmm... Very strange... It -should- work... What does %NETDRV% get
>replaced with? What DOS version are you using? What command
>interpreter (COMMAND.COM/4DOS)? In any case, it is not a problem of
>SCAN; it is a problem of the operating environment you are using...
>
>[Moderator's note: I agree that this appears to be a problem with the
>operating environment, and I'd like to request that follow-ups get
>handled via e-mail, with the exception of a follow-up summary of the
>solution (if anyone cares to post one).]

There's nothing wrong with his operating environment; chalk this one up
to user error.  He's typing those lines at the command prompt -- DOS only
replaces environment variables when interpreting lines of batch files.
Put those lines in SCANIT.BAT and it would work.

(Try typing "echo %COMSPEC%" at the command prompt and see what you get.)

I'm cc'ing this solution to Craig.

Regards,
David R. Conrad
David_Conrad@mts.cc.wayne.edu, dave@michigan.com


------------------------------

Date:    22 Dec 92 12:51:18 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Integrity Management (PC)

RADAI@vms.huji.ac.il (Y. Radai) writes:

> ing").  First, you write as if all algorithms have a seed.  Well, in

My initial thought was that the database of checksums is kept on-line.
If it isn't (i.e., if it is stored on a write-protected diskette),
then you don't need any cryptographic checksum, of course. But if it
is, you cannot just use plain MDx or any other known keyless
algorithm, because a virus could use the same algorithm to compute the
new checksum of the infected file and update the database of checksums,
so that everything will look OK... In these cases, you -must- have
some kind of key that is kept unknown to the virus.

> the case of the MDx algorithms, I suppose you could say that the
> initial contents of the buffers constitute a seed; also that DES has a
> seed when used for authentication purposes (ANSI X9.9), namely the
> initial block.  But what do you mean by "using a different seed for
> the checksum" in the case of CRC?

Well, a CRC is usually computer like this:

	crc = INITIAL_VALUE;
	while ((c = getc (file)) != EOF)
		crc = crc_table [(crc & 0x00FF) ^ c] ^ (crc >> 8);

Usually INITIAL_VALUE is 0, but you could set it to anything you would
like...

>   More important, in the case of MDx and X9.9, how do you know that
> varying the seed is enough?  You *may* be right, but to the best of my
> knowledge, neither the buffer contents of MDx nor the initial block of
> X9.9 were designed for that purpose. 

You are right, I don't know whether it is secure enough. But you have
to do something with the keyless algorithms, if you want to achieve
different checksums for each user and not allow the virus to guess the
correct checksum of the modified object...

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

------------------------------

Date:    22 Dec 92 13:26:30 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: SVC 6.0 not rem. by F-PROT206a (PC)

kratz%orville@uunet.UU.NET (Thomas Kratz) writes:

> A week ago I had two guys with their pc's in our office who had
> cought the SVC virus in version 6.0.

Gosh, how did you manage to get infected by this relatively not
widespread Russian virus?!

> SCAN V99 reported [SVC] and(!) [SVC 5.0] in the boot sector and on
> various .com & .exe files, an information I decided not
> to trust, because of the multiple report of infection.

Right, SCAN 99 incorrectly reports two infections for this virus. If
there is enough interest, I could post a full list of viruses that
SCAN 99 detects as more than one.

> F-PROT found (correctly) SVC 6.0 (4644 bytes), but only on the .com & .exe
> files.

The virus also infects SYS files. If F-Prot does not say this or if it
does not detect this, then it is a bug.

> After removing the virus (which f-prot claims to do correctly)
> all infected files were absolutely identical with the originals, that were
> present on security-disks, but knowing that SVC 6.0 does infect the boot-
> sector i ran scan again; with the result, that it reports [SVC] and [SVC5.0]
> still present in the boot sector.

Sounds indeed like a bug in F-Prot to me... The virus is indeed
multipartite and infects boot sectors, COM, EXE, and SYS files. It
also does funny things to the source of the program AIDSTEST
(AIDSTEST.C), if it finds it... This is a Russian anti-virus program,
written by Lozinsky.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

------------------------------

Date:    22 Dec 92 13:35:04 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Virus Simulator MtE Available (PC)

frisk@complex.is (Fridrik Skulason) writes:

> I just hope that everybody realizes that the ability of a program to
> detect the files generated by the "Virus Simulator" does not at all
> indicate if it will detect the actual viruses or vice versa, which
> makes this effort quite pointless, IMHO.

Well, I tend to agree with you, just maybe "not at all" is a too
strong expression. Depending on how exactly his dummy files are
generated, their detection might, or might not be connected with the
ability of a scanner to detect the MtE-based viruses. I suspect that
he's using the MtE itself to generate them. In this case, not
detection of one of them by a scanner does not necessarily mean that
the scanner will not detect the real virus, but in any case should
prompt further investigation...

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 22 Dec 92 09:57:21 -0500
From:    Jon Freivald <jaflrn!jaf@uunet.UU.NET>
Subject: Chkdsk / undelete fix from Microsoft. (PC)

In line with our discussion of the CHKDSK bug in DOS 5.0, I received
an upload on my BBS from a user who has a relative who works for
Microsoft.  It contains a text file, as well as a new chkdsk.exe and
undelete.exe.

For any who wish to obtain this, you can download it by calling (516)
483-5841, n-8-1, 300-9600.  Sorry, due to feed troubles my mail-server
is off-line.  The file is /public/dos/chkupdt.zip.

Jon

=============================================================================
                   Jon Freivald ( jaf%jaflrn@uunet.UU.NET )
	 Nothing is impossible for the man who doesn't have to do it.
=============================================================================
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqxd1UAAAEEAMFukk0cHx1XUSNdnwuDC9+paXaH5DAQfRQaADxoTQddbh/P
UJ9GAfFvpmnTYNvNjZYZ6GtMS8E/VlNyPnpqNuqbFVkDJhhBTYq5FeKBZVHItSNW


------------------------------

Date:    Tue, 22 Dec 92 14:37:55 -0500
From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Clearing out old signatures (PC)

Enclosed is a DEBUG script that will create a 68 byte .COM file
(CLEAR.COM) that will zero out memory between the current load
position and the TOM. To use, extract the portion of this message
between the (cut here) lines and name it CLEAR.DEB (the portion
beginning with "a100" and ending with the blank line after the
"q" - NOTE: that last blank line must be there as must the blank
line following "JMP 102". 

Next run "DEBUG <CLEAR.DEB" When run there should be no errors.
This will create the program CLEAR.COM.

NOTE: It will not clear the disk buffers or any high/upper RAM
      nor will it remove any viruses that are properly resident
      in allocated space, it just clears free memory.

Weasel-words: this is FreeWare but carries no guarantee of fitness
              of any kind. Caveat etc. 

- ----beginning of CLEAR.DEB------------8<------cut here-------------
a100
JMP	010D                 ;skip around loop
MOV	ES,AX                
XOR	AX,AX                
MOV	DI,AX                
REPZ	                     ;clear out memory
STOSW	                     
MOV	AX,ES                ;replaced by CD 20 for last loop
RET	                     ;move stack to protected area
MOV	AX,0100              
MOV	SP,AX                
MOV	DX,CS                
MOV	SS,DX                ;make sure program does not get
ADD	DX,+20               ;overwritten until end
INT	12                   ;Find the TOM
MOV	CL,06                
ROL	AX,CL                
SUB	AX,1000              ;Can only clear 64k at a time
CMP	AX,DX                ;Make sure we are not back down
JBE	012E                 ;to where program is.
MOV	CX,8000              
CALL	0102                 ;if not, clear 64k
JMP	011F                 ;then try again
MOV	WORD PTR [010A],20CD ;last loop - put termination in 
SUB	DX,+0F               ;can overwrite most of program
MOV	AX,DX                
MOV	CL,03                ;DX contains amount of this segment
SHL	DX,CL                ;that is in use plus loop.
MOV	CX,8000              
SUB	CX,DX                ;Subtract from 64k gives amount to
JMP	0102                 ;clear. No return so JMP not CALL

rcx                                         
44
nclear.com
w
q

- ----------end of CLEAR.DEB---------8<--------cut here--------
             *
             |
            abc
           defgh               And a Merry Christmas to All,
          ijklmno
         pqrstuvwx                               Padgett
        yzabcdefghi
       jklmnopqrstuv
           wxyz
          __||__

------------------------------

Date:    Mon, 21 Dec 92 23:24:08 -0500
From:    "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>
Subject: "Beneficial" viruses

I believe that Fred Cohen, who is flogging his "beneficial" viruses 
again, is being very mischievous, and doing the industry a great 
deal of harm.  I gather that in fact these are not viruses at all, 
in the sense that we use the term.  They may fit Fred's original 
definition, but the modern definition makes much more sense, and it 
is impossible for Fred to turn the clock back single handed, any 
more than I can resurrect the original meaning of the word "gay".

Fred is well aware of this, but he persists in using the term 
"virus" for his product, as he knows it will get him far more 
publicity, but when you attack him he says 'Are you going to ban 
FORMAT?', which, by his definition, is apparently a virus.

The trouble with this talk of 'good' viruses is that it provides all 
the would be virus writers in our schools with the perfect 
justification for their activities.  After all, if Dr. Fred Cohen is 
selling 'good' viruses, why shouldn't they see if they can do the 
same?

He makes the situation even worse when he announces that he has made 
1500 viruses in an afternoon, and that this shows scanners are dead.  
In the first place it shows nothing at all, as no one is interested 
in viruses until they enter circulation, and in the second place it 
provides evidence for the skeptics who believe that we amuse 
ouselves in our spare time writing viruses to keep ourselves in 
business.  Unfortunately there are already so many kids trying 
to emulate Fred, that none of us have the time, let alone the need, 
to write viruses.


Seasons Greetings to everyone.

Roger Riordan                     riordan.cybec@tmxmelb.mhs.oz.au

CYBEC Pty Ltd.                                 Tel: +613 521 0655
PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: +613 521 0727

------------------------------

Date:    Tue, 22 Dec 92 10:04:27 -0500
From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Checksums, signatures, and "good enough" algorithms. (Generic)

From:    Y. Radai <RADAI@vms.huji.ac.il>

>  Padgett Petersen wrote:
>>> I agree but take it one step further, again the algorithm should be
>>> tailored to the specific machine and use a different seed on each - this
>>> in no way weakens the algorithm but gives each PC a different signature
>>> for a particular file. Break one machine and "malware" must start all over
>>> again on the next.

>  Vesselin Bontchev replies:
>> In fact, it depends on the algorithm used. If you are using a CRC,
>> just using a different seed for the checksum does not make it secure -
>> you must change the polynomial each time. If you are using something
>> cryptographically strong as DES, MD4, MD5, MD2, or some such, then
>> just changing the seed is enough.

>I agree with part of this.  Yes, it depends on the algorithm, and
>using a different seed does not necessarily make an algorithm secure.

Ok, I did not explain fully. This is a expansion of a discussion that
Ross Greenberg, Yisreal Radai, & I had in Virus-L about two years ago.

The complete concept did not use a single algorithm, rather it was
selected from a 3x3 matrix at the time of installation. Combine a 1 of
nine algorithm with a unique seed and you have a signature that is
difficult for software to forge - at least forging the signature would
be more difficult than breaking the mechanism.

First a sample matrix:

Row:         ROL  ROR  NOP
Column: XOR
        ADD
        SUB

In practise the code might select two to make things more difficult
& would look something like this for .COM files (stages would be needed
for .EXEs over 64k). CX contains the file size. DS points to the file in
memory.
    
Row:         ROL  ROR  NOP
Column: XOR  BX
        ADD       DX
        SUB


    XOR SI,SI
    MOV BX, sig1
    MOV DX, sig2
L1: LODSB
    XOR BL,AL
    ROL BX,1
    ADD DL,AL
    ROR DX,1
    LOOP L1

(please, no jibes at the algorithm - this is just an example)
   
Appending  BX to DX would produce a 32 bit signature. A final confusion
might be whether the order is BX-DX or DX-BX. Since we have three unknowns
(initial seed, algorithm, final order) that are selected at installation,
it becomes very difficult for malware to determine which is acually in use.

The easiest way is to compare a known program with its signature but even
there there are many crossing points & if the wrong branch is taken, the
forgery will fail. Further the process will have to start from scratch on 
the next PC.

Now, it becomes easier for the malware to try to break the program than 
to forge a signature so armoring is the next step.

The basic point is that the above code is very tight so performance
would not suffer (in tests I have been able to process nearly 64k/second
on a 4.77 Mhz 8088 PC). The selection process can take a little longer
since it is only done once. 

The above is an example of quantum economics: the strenght of the algorithm
is matched to the speed of the process and the strength of the process
itself. IMHO there is no point in making the signature any stronger since,
unlike DES, it is never transmitted outside the PC it is used on (and,
in fact the user never needs to know what it is).

I trust this is sufficient explination.


             *
             |
            abc
           defgh               And a Merry Christmas to All,
          ijklmno
         pqrstuvwx                               Padgett
        yzabcdefghi
       jklmnopqrstuv
           wxyz
          __||__

------------------------------

Date:    Tue, 22 Dec 92 14:29:28 -0500
From:    celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta))
Subject: Definition of computer virus (was FC on virus creation)

Hello everybody,

I was following for some time discussion about ethical correctness of
Fred Cohen's virus creation. It seems to me that most of dilemmas
arises from different understanding of term computer virus. I am
relatively new on this list, so don't know if the definition of
computer virus was properly discus- sed earlier and if some general
definition was accepted. If was I would like to know which one. I saw
different definitions in literature (I looked in the VIRUS-L FAQ too
:-))and would like to sublime what I've read till now in following
statement :

      Computer virus is set of instruction written with intention to
cause some unwanted function in system in which is currently situated.
Virus has ability of reproduction, it can propagate through different
media, may evolve over time and can mutate.

Is that correct definition ? I would really like to know one which
wouldn't lead to misunderstandings.
                                                                           
 Cheers,                                       ______________              
                                              |              |             
 Suzana                                      /|  Who am I ?  |             
                                 /~~~~~~\~\ / |______________|            
                                (  * *   )/            
                               /(  ___   )                                 
                              ~  \______/                                  
                                @/       \@       

- ---------------------------------------------------------------------------
Address: Suzana Stojakovic-Celustka          e-mail addresses:
         Department of Computers             celustka@sun.felk.cvut.cs
         Faculty of Electrical Engineering   celustkova@cs.felk.cvut.cs
         Karlovo namesti 13
         12135 Prague 2                      phone : (+42 2) 293485   
         Czechoslovakia                      fax : (+42 2) 290159

------------------------------

End of VIRUS-L Digest [Volume 6 Issue 2]
****************************************
