VIRUS-L Digest Thursday, 19 Sep 1991 Volume 4 : Issue 166
Today's Topics:
re: Scanning LZEXE and PKLITE files (PC)
Scanning LZEXE and PKLITE files (PC)
Re: Disinfectant and students (Mac)
Re: Stoned virus (PC)
When will FPROT 2.00 work with Zenith Dos 3.30.1 (PC)
Re: FAT Infection (PC)
F-prot, Clean, Joshi and DOS 2.0. (PC)
Possible virus on Cypress Semiconductor 5.25 inch disks (PC)
Re: Heuristic analysis
Re: SunOS virus checker needed (UNIX) (PC)
Re: Heuristic analysis
The "Azusa" virus (PC)
Re: FAT Infection (PC)
Re: Virus Simulator available (PC)
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. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Wed, 18 Sep 91 17:09:03 -0400
>From:
[email protected]
Subject: re: Scanning LZEXE and PKLITE files (PC)
> Not altogether true, I fear. I'm hearing reports that some programs
> don't work any more afer tering de-compressed as such, particularly in
> the case of LZEXE.
Certainly, just because a virus-scanner does not go off does not mean
that you should feel complete confidence. It is true that LZEXE'd
files often do not decompress back to their original parents. It is
also true that UNLZEXE often botches things up such that the UNLZEXE'd
file will not load and run even though the LZEXE'd file will. Most of
this has to do with .EXE relocation information in the header (LZEXE
is good at munging a lot of this), and should not affect searching for
string signatures. PKLITE is better in that unless you choose the
option which purposes strips the executable of extra data (such as
debugging information inserted by CodeView), it is capable of
decompressing files which it compresses back to the original, byte for
byte. Testing this on many .EXE and .COM files seems to even
corroborate PKWare's claim.
------------------------------
Date: Wed, 18 Sep 91 18:01:17 -0400
>From:
[email protected]
Subject: Scanning LZEXE and PKLITE files (PC)
> The dilemma really is that, for example, all PKLITE'd executables
> cannot be expanded. Perhaps it wasn't such a hot idea to sell the
> unexpandable compression version by PkWare.
If you PKLITE an arbitrary executable, *ANYONE* can decompress it with
their copy of PKLITE. Developers who wish to make it less easy for
anyone who may wish to be able to examine their code may register for
a customized copy of PKLITE whose output cannot be decompressed by
end-user PKLITE. This is bad in that even the largest commercial
developers have been known to be inadvertently infected and distribute
infected applications, and if they choose to get the special PKLITE,
we can no longer check the original code ourselves. However, it isn't
easy for malicious virus-writers to insert their virii into such files
at the source -- so I don't think this is much of a concern.
------------------------------
Date: Wed, 18 Sep 91 23:34:18 +0000
>From:
[email protected] (Leo D. Geoffrion)
Subject: Re: Disinfectant and students (Mac)
Since folks are flaming sites that keep virus knowledge secret, I
thought it might be useful to mention a slightly more enlightened
approach...
At our College, we install the disinfectant init in EVERY system disk
given out to users. Whenever an infection is detected, we place a Mac
next to the main door to the public user room and instruct the student
assts. to check every disk that comes in. If it's clean, they
install the latest edition of Disinfectant. Simultaneously, we send
out e-mail notices to all of the academic departments whenever a new
outbreak is detected.
Over the past few years, there have been outbreaks of several Mac
viruses (NVIR, SCORES, WDEF, ...) but we've usually managed to beat
them back within a couple of weeks. Virus infections are most common
after vacations or toward the end of the school year when most folks
are hurrying to complete projects and get careless about their disks.
------------------------------
Date: Thu, 19 Sep 91 12:36:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Stoned virus (PC)
[email protected] (Brian Cooper) writes:
>... My system checked out fine. I used the /a and
> /m options so all the files were checked as well as the boot
> sector and memory. I then started scanning some old floppies
> that I had. I found about a dozen floppies containing the
> Stoned Virus in the boot sector...
> What does it mean when a virus is in the boot sector of a floppy
> disk? How could such a virus become active when there are no files
> executable files containing the virus?
Note that this sort of virus isn't found in programs, but in the
"hidden" first sector of disks, and it hasn't become "active" in your
computer (at the moment) but must have been in some other computer
your diskettes were used in.
If you can remember what computers they were used on (even to simply
transfer data files), you should warn their owners to check for
viruses (but, of course, it is hard to remember everywhere old
diskettes have been, hence the success of boot sector viruses like
stoned).
What does this mean? Well, when most computers start up, they look at
the first sector of the first track on the disk(s), and load whatever
program is there; this should be a bootstrap program, to load the full
operating system. If the operating system isn't there it should tell
you to try another disk. Just to compicate things, modern MSDOS
systems have another level inserted - the "MBR" or partition table
contains a table of information about partitions on teh disk, plus a
bit of code to load the bootstrap program (which pretty much carries
on as if it were the first sector to be executed). Boot sector viruses
act just like that - they inhabit the boot sector of a diskette (or
one of the boot sectors - if you call the MBR a boot sector - of hard
disks); they install the virus in RAM somewhere, and then call the
original boot sector, which executes as if nothing was changed. A
diskette can get a boot sector virus even if you put it in an infected
PC to transfer data (or even do a directory listing!), but it won't
transfer the virus onto another computer unless you try to boot from
it (which includes leaving it in the drive accidentally when you
switch on or do a Ctrl-Alt-Del). Notice, you only need to *try* to
boot from it - if the diskette doesn't have an operating system (and
you get the "non-system disk" message) your computer can still be
infected.
Hope this helps,
Mark Aitchison.
------------------------------
Date: Thu, 19 Sep 91 01:10:29 +0000
>From:
[email protected] (Douglas A. Bell)
Subject: When will FPROT 2.00 work with Zenith Dos 3.30.1 (PC)
When will the fix be out?
- --
Douglas Bell
[email protected]
I can only have a four line .sig I'll never make alt.fan.warlord
------------------------------
Date: Thu, 19 Sep 91 13:59:00 +1200
>From: "Nick FitzGerald" <
[email protected]>
Subject: Re: FAT Infection (PC)
In VIRUS-L Digest V4 #164 I wrote:
>At this point there is much potential for confusion. Some BSI/PTI
>viruses _affect_ (NOT infect) the FAT. This happens with Stoned and
>most of its derivatives, due to the "assumption" by its creator, that
>sector 0,0,7 is never used. This is true on HD's FDISK'ed with
^^^^^^^^^^^^
>pre-3.0 versions of DOS, some OEM's DOS 3.X'es, and some third party
>partitioning progs that do not leave an unused track at the beginning
>of the disk. ...
The gremlins got me 8-). Despite several re-readings, I missed an
obvious blunder, which probably rendered this paragraph
unintelligible.
The highlighted part should read "This is _not_ true"
Sorry,
- ---------------------------------------------------------------------------
Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
Internet:
[email protected] Phone: (64)(3) 642-337
------------------------------
Date: Thu, 19 Sep 91 01:12:00 -0400
>From: George Svetlichny <
[email protected]>
Subject: F-prot, Clean, Joshi and DOS 2.0. (PC)
Last week I was asked to disinfect a 5 1/4 in. - 360K bootable floppy
with Print Shop installed and infected with Joshi. I was told that the
user had tried to remove the virus but was unable to do so. I started
with Fridrik's F2 (Part of FPROT 2.00) as in the past I've had the
most sucess with F-prot in removing Joshi. The program identified the
infection and reported removal, yet a repeated scan again reported the
presence of the virus. The disk would not boot, though I don't know if
it would have booted before I ran F2 on it as I didn't try to. Passing
on to McAfee's SCAN and CLEAN I had the same experience, the CLEAN
programm reporting removal, and a subsequent scan reporting continued
presence. Examining the boot sector I noticed that it was formated
with DOS 2.0, and the system files were DOS 2.0 also. Luckily enough I
had a copy of DOS 2.11 stashed away and a simple SYS command (well,
not *so* simple, I had to manually free the necessary space - later
DOS version could not have fitted on the disk along with all the other
files) seems to have resolved the problem and I was able to return a
functioning floppy to the owner (Print Shop uses a rather silly copy
protection scheme so I couldn't just copy all the files to a clean
disk; one more reason to say no to copy protection.). What intrigues
me though is the thought that the problem could have been due to the
old DOS version. Could F2 and CLEAN have some problem with DOS 2.0?.
As there are probably still a lot of bootable floppies with old DOS
versions in action, such a situation would be at best an
inconvenience.
George Svetlichny |
Departamento de Matematica |
Pontificia Universidade Catolica |
Rio de Janeiro, Brazil |
|
[email protected] |
------------------------------
Date: Thu, 19 Sep 91 09:42:15 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Possible virus on Cypress Semiconductor 5.25 inch disks (PC)
We have received notification of a possible virus on Cypress
Semiconductor 5.25" floppy disks identified as MAXPROG version 2.72C
dated May 1991.
It is said that these disks contain the STONED virus in the boot
sector. 3.5" disks and programs downloaded from the Cypress BBS are
said to be clean.
Since this is specialized software used in the programming of memory,
it is doubtful that many copies have been sent out. Cypress is
reported to be in the process of contacting known recipients of the
disk.
Padgett Peterson
------------------------------
Date: Thu, 19 Sep 91 16:59:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Heuristic analysis
[email protected] (Bob Babcock) writes:
>>> Frisk's "heuristic virus analyzer"
>>> is *extremely* prone to false alarms, much more so than his string
>>> scanner.
>>You probably tested it on some programs that were badly written, used
>>self-encryption or modification, modified executable files, and in
>>general behaved in an unusual way...
>
> I've written some code which does none of these things, yet it still
> triggers a false alarm. This is code which I sell, so I'm not going
> to be happy if customers start complaining that a heuristic scanner
> claims that it may be virus infected...
Of course, remember his program gave plenty of warnings that this was
only experimental, and it isn't called in by default when scanning for
viruses, so there should be little worry on the part of uneducated
users.
>... I raise
> this as a practical problem with this sort of scanner, distinct from
> the theoretical problem that a perfect scanner is impossible.
Hmm, this sort of thing is likely to happen a lot now, as we seem to
be at the start of a new generation of virus scanners (at last!, some
would say). In some ways it parallels the days when very simple string
scanners were made, with libraries of virus strings not produced as
carefully as today. I feel the answer is not to avoid heuristic
scanners, but to improve their hit rate before being released by some
organisation establishing a huge library of good and infected files,
and providing a certification of anti-virus products for free, inthe
interests of everybody. I must say that I ran this particular program
on what I think is a large number of files, and (apart from compressed
files, and ones obviously odd to me, at least) the number of false
alarms was small. But I doubt it could ever be zero.
Mark Aitchison, Physics, University of Canterbury, New Zealand.
------------------------------
Date: 19 Sep 91 09:26:10 +0000
>From:
[email protected] (Tommy Pedersen)
Subject: Re: SunOS virus checker needed (UNIX) (PC)
[email protected] (Vienna) writes:
>Looking for SUN/OS compatible Virus checker program
>Like many LANs , Ours Files servers are UNIX based but also support
>the MS-DOS community. I am looking for a SUN/OS binary or coding which
>can be ran by the CRONTAB automaticly at set times.
>It will only need to scan the MS-DOS file sectio sections or sections
>requested.
>Anybody have any ideas?
>Anybody working on such a program?
>
[email protected]
>Yasha "John" Kida
>[Ed. The COPS package, among other things, does perform CRC integrity
>checks on selected binaries. It is available for free by anonymous
>FTP on cert.sei.cmu.edu in pub/cops, and runs on most any UNIX
>system. Could be a good place to start.]
Well using a regular CRC integrity check does help, but it is not a general
solution. A virus can easily fool the checksumming program by simply adding
a pattern which makes the checksum correct. This approach would therefore
only work if the checksumming algorithm is kept secret, but that is of course
not a good solution.
A better and general solution is to use cryptographic checksums. It is then
free to distribute the algorithm used since the secret relies upon a small
key which can be changed very often and individually for the users. A virus
can not add a pattern which makess the checksum correct since it not knows
which key that has been used. The only way would be to break the crypto, and
that is much more involved than just adding a pattern.
If you would like to get some info on a commercial packet for unix machines,
calculating cryptographic checksums, send me an email to "
[email protected]".
Running a checksumming program (cryptographic or not) on a unix host obviously
has the advantage of beeing immune against stealth viruses, since it is not
the same machine that does the checksumming that may be infected. A check-
summing program on the PC must be started after booting from a "clean" discette.
- --
/Tommy Pedersen
______________________________________________________________________
|E-mail:
[email protected] /\ |
|S-mail: Tommy Pedersen / / Telephone: +46 13 235200 |
| SECTRA-Secure Transmission AB | | FAX: +46 13 212185 |
| Teknikringen 2 |.> |
| S-583 30 Linkoping |/ |
|_______ SWEDEN ______________________________________________________|
------------------------------
Date: 19 Sep 91 09:06:23 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Heuristic analysis
[email protected] (Bob Babcock) writes:
> I've written some code which does none of these things, yet it still
> triggers a false alarm. This is code which I sell, so I'm not going
> to be happy if customers start complaining that a heuristic scanner
> claims that it may be virus infected. Worse, I have no clue as to
> what the scanner is finding, so there's no way I can change the code
> to quiet the scanner. If the algorithm used by the scanner is
> released, or if the scanner is more specific about what code it found
> which indicates possible infection, then virus writers can use this
> information to write viruses which the scanner can't see. I raise
I suggest that you send an example of your program that triggers the
alarm to Frisk. This may help him to modify and improve his algorithm,
and also he will probably suggest you what modifications to make in
order to avoid the alarm.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: Thu, 19 Sep 91 09:52:00 -0400
>From:
[email protected]
Subject: The "Azusa" virus (PC)
Hi,
I just came accross the AZUSA virus the other day. It appeared at
boot up along with a STONED related virus. I was not able to clean it
because it did not appear at the next boot up.
Does anybody know what this virus does? What programs will clean it?
Thank you for any information.
Chris Kunselman
------------------------------
Date: 19 Sep 91 08:17:41 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: FAT Infection (PC)
[email protected] (Brian J Moore) writes:
> >If it overwrites only the first FAT copy, you won't lose anything...
> >and you probably won't even notice that something nasty has happened.
> Running CHKDSK will tell you if the FATs don't match...
It won't, if the virus modifies the DPB to indicate that there is only
one FAT copy...
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 19 Sep 91 09:15:59 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Virus Simulator available (PC)
[email protected] (Matt Ender) writes:
> Last note of interest: I don't notice too many new viruses derived
> from old viruses (example, the 'strains' of a particular virus.)
> Thus, I must deduce that the authors either have stopped writing
> viruses or don't bother watching the scanners and re-writing their
> viruses.
To my knowledge, more than 30 % of the known viruses are Vienna,
Jerusalem, Cascade, or Amstrad strains. The question, however, is how
many strains have been created just to fool a particular scanner. Does
anybody have any information on this?
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 166]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
