home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-385-Vol-1of3.iso
/
v
/
vl6-2.zip
/
VL6-2.TXT
< prev
Wrap
Internet Message Format
|
1993-01-15
|
40KB
From lehigh.edu!virus-l Thu Jan 7 07:06:32 1993
Date: Tue, 5 Jan 1993 10:09:29 -0500
Message-Id: <9301051402.AA11929@barnabas.cert.org>
Comment: Virus Discussion List
Originator: virus-l@lehigh.edu
Errors-To: krvw@cert.org
Reply-To: <virus-l@lehigh.edu>
Sender: virus-l@lehigh.edu
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <krvw@cert.org>
To: Multiple recipients of list <virus-l@lehigh.edu>
Subject: VIRUS-L Digest V6 #2
Status: R
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]
****************************************