VIRUS-L Digest Tuesday, 28 May 1991 Volume 4 : Issue 90
Today's Topics:
Re: Tequila virus (PC)
Re: Virus Statistics
Hoffman Summary & FPROT (PC)
Re: Tequila virus (PC)
VSUM Format (PC)
Question About Stealth Viruses
Re: Software Upgradable BIOS (PC)
MS-DOS in ROM (PC)
DISKSECURE 95 (PC)
Re: "Horse" Virus Family (PC)
Delta virus (PC)
Review of SafeWord Virus-Safe (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: Thu, 23 May 91 16:39:24 -0400
From: Padgett Peterson <padgett%
[email protected]>
Subject: Re: Tequila virus (PC)
Ross: It would be interesting if you, Frisk, & I ever get together
at a bar but they'll have to provide a padded room & unbreakable glasses.
>From:
[email protected]
>>From:
[email protected] (Morgan Schweers)
>>
>> *Chuckle* It's a variant of the Flip virus, actually. A bit of
>>psuedo-encryption code was added, and a bit of infection code was
>>removed, but otherwise it's mostly flip-like.
>Interesting phrase, "psuedo-encryption". What, exactly, does it mean?
(Can't help myself, this is too much like "mock-swedish") Given that
encryption covers both codes (breakable) and cyphers (less so), it
would follow that a "pseudo-encryption" is neither a code nor a cypher
but looks like one. EBCDIC & BAUDOT would probably fall into that
category as would the raw output from most word processors. For that
matter, a DEBUG U(nassemble) of a Master Boot Record) is gibberish to
one who does not understand the conditionals but makes perfect sense
once the constraints are understood. The output from a "Little Orphan
Annie Secret Decoder Ring" would not be "pseudo" since it produces a
real (though trivial) code.
>Sorry: I don't count "wild card" strings as a search pattern. There's
>too much chance for false positives.
Why do you disagree with "wild cards"? For example, if I find a boot
sector that contains MOV AX,[413] <some code> MOV [413],AX I would
suspect a virus reguardless of what went on in the <some code> area.
To me a variable length "wild card" to replace <some code> would be
very useful in this case.
I agree that the potential for false positives exists, but as an
intial mechanism that determines a maxterm/minterm decision tree
structure or to provide a public signature without revealing to much
of the viral design, such a "wild card" function would be very
effective.
Warmly,
Padgett
------------------------------
Date: Thu, 23 May 91 18:32:18 -0600
From:
[email protected] (Richard W Travsky)
Subject: Re: Virus Statistics
I've often wondered if anyone was keeping track of viral infections.
Myself, I've wondered about the geographic spread (as in, a [new]
virus shows itself here, then here, and then there). Would make some
pretty plots, like the spread of killer bees ;)
For the record, before last fall my site, the University of Wyoming,
did not appear to have much in the way of virus activity - at least,
none that anyone bothered to report to us. And also for the record,
the two we have now are Stoned and Ping Pong (Ping Pong appears to be
confined to the Law College - read in to that what you will! ;). A
while back, Jerusalem put in an appearance, but it did not apparently
spread. I've a couple of unconfirmed reports that MusicBug is in town
(via FTP is what I've heard).
I'm sorta curious about factors facilitating virus spread. The
closest town to us is about 50 miles away - physically.
Electronically, well, ftp makes for a small world. Our school size is
about 10,000. What else might be pertinent? Perhaps a profile could
be drawn up?
+-----------------+ Richard Travsky
| | Division of Information Technology
| | University of Wyoming
| |
| | RTRAVSKY @ CORRAL.UWYO.EDU
| U W | (307) 766 - 3663 / 3668
| * | "Wyoming is the capital of Denver." - a tourist
+-----------------+ "One of those square states." - another tourist
Home state of Dick Cheney, Secretary of Defense of these here UNITED STATES!
------------------------------
Date: Thu, 23 May 91 18:38:19 -0600
From:
[email protected] (Richard W Travsky)
Subject: Hoffman Summary & FPROT (PC)
I have the March 17th P. Hoffman virus summary in front of me and
something has attracted my notice: The version of FPROT she refers to
is version 1.07. The current release is 1.15A and 1.16 is due out in
June.
Any reason why such an old version is used?
Richard Travsky
Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming (307) 766 - 3663 / 3668
------------------------------
Date: Thu, 23 May 91 20:45:22
From:
[email protected]
Subject: Re: Tequila virus (PC)
>From: "David.M.Chess" <
[email protected]>
>
>.... Any sort of
>less-than-virus-length scan string is somewhat prone to false alarms,
>but ones with wildcards, if properly chosen, aren't necessarily any
>worse than ones without...
We'll have to agree to disagree on this one, Dave.
Ross
------------------------------
Date: 23 May 91 09:23:37
From:
[email protected]
Subject: VSUM Format (PC)
[email protected] (Volkmar Kuhnle) writes:
>But over the months al lot of new viruses (and strains of existing ones)
>have been uncovered, so that VIRUSSUM.DOC grew in size. Since the
>current version is about more than 500 K in length, is is getting
>harder and harder to find informations about a special virus in
>a file of this size, since I have to use a normal editor.
>
>I came to the conclusion that an ASCII file is not appropriate for the
>distribution of so much data. Therefore I would suggest to supply
>future versions as DBF files (dbase format).
Other people may have beaten this to death but I propose that Patricia
Hoffman change her VIRUSSUM.DOC to something similar to PC Virus Index
(PCVI305.zip) by Dan McCool and Brian Clough. This file comes with an
executable portion and separate datafiles for each virus. This is a
well written program that is easy to use.
------------------------------
Date: 23 May 91 23:21:40 -0400
From: "Robert McClenon" <
[email protected]>
Subject: Question About Stealth Viruses
I have a question, or probably a series of related questions. Can
someone please explain exactly what "stealth" viruses are? Is there a
standard definition of what characteristics make a virus a "stealth"
virus? If not, what are the alternate definitions? I have read that
they delete themselves from the hard disk and hide in memory when they
are active. If so, can't they be disinfected by simply powering off
the workstation? If not, exactly what are they doing and how? I
apologize if I am wasting the time of some readers, but I assume that
there are others who also want to know this.
Robert McClenon
Neither my employer nor anyone else paid me to ask this.
------------------------------
Date: 24 May 91 05:38:55 +0000
From:
[email protected]
Subject: Re: Software Upgradable BIOS (PC)
[email protected] (William Walker C60223 x4570) writes:
>Here's something that should make the anti-virus community cringe.
>Intel has announced a chip which would allow users to upgrade their
>BIOS using a floppy disk. The term I saw was "erasable programmable
>read-only memory (EPROM)," but more likely the actual technology in
>the chip is EEPROM (electrically erasable programmable ROM) or EAROM
>(electrically alterable ROM).
Intel is planning on using Flash EEPROM technology, but, as I
understand it, with a twist -- The user will have to explicitly
activate the reprogramming function by pressing a button, flipping a
switch, or some similar physical function. Fortunately, since no
forseeable virus technology will allow the little beasties to reach
out and press a button, I don't believe there is that much to worry
about in this technique. (I hope :-)
>Bill Walker (
[email protected] ) |
>OAO Corporation |
>Arnold Engineering Development Center | "I'd like to solve the puzzle, Pat"
>M.S. 120 |
>Arnold Air Force Base, TN 37389-9998 |
Brendt Hess a.k.a. | Disclaimer: Opinions? I don't even work here!
Vergil William de Comyn a.k.a. |-----------------------------------------------
Payne Hirds | Life is not a zero-sum game:
[email protected] | don't treat it as such.
------------------------------
Date: Fri, 24 May 91 11:15:57 -0400
From: padgett%
[email protected] (A. Padgett Peterson)
Subject: MS-DOS in ROM (PC)
I can see that some background is going to be necessary as this looks to be
an on-going discussion.
Firstoff, starting MS-DOSs not a single file, it is a collection of files,
all of which are used yet not all of which remain resident. These include
IO.SYS, MS-DOS.SYS, and the familiar COMMAND.COM. Even in DOS 3.3, probably
the most common version, a little examination will reveal that these three
files take up around 150k bytes on the disk.
Next, if you look at the interrupt table and BIOS data structures, you will
that another 3k are occupied before DOS ever starts. Yet on a 640k machine,
there is about 595k free space left with a bare DOS loaded. This means that
only about 45k of low memory is in use when the C:\ prompt appears (& no TSRs
are loaded. Obviously this doesn't add up, where did the other 100+k go ?
Part of it is in the transient part of COMMAND.COM loaded into the TOM (top
of memory) but COMMAND.COM is only about 25k so even if all were transient,
we would still have 85k or over half of MS-DOS unaccounted for.
The answer is that while all of MS-DOS is used, part of it is only necessary
for start-up. Once these segments are complete, the memory occupied by
structures like SYSINIT is released back into the free space for re-use just
like when an application is complete, the space occupied is reuseable by the
next program. With ROM this is more difficult.
Thus, while the permanent portion of MS-DOS is ROMable, the transient half
must use one of three choices:
1) Keep on volatile disk & map in and out of RAM as is done now.
2) Place in ROM & reduce free memory space (high memory above segment C000
could be used but with the proliferation of memory managers to load
TSRs "high", for many users today this would have the same effect as to
reduce free "low" memeory. ROMed laptops generally use this technique.
3) Add circuitry to map in ROM to available address space & remap to RAM
when done ($).
The hooker is that the data areas (interrupt table, BIOS data, DOS data)
MUST remain in RAM or undergo major structural changes (2k of CMOS is
a possibility), and these are the areas that viruses generally attack.
Unfortunately, in the case of many popular applications (1-2-3, Windows,
etc.) these would also have to be rewritten to accomodate the new structure
(see Apple III, LISA, Mac 128, DEC Rainbow & DECMATE for the effects of such
changes/differences).
Additionally, as AZUSA has demonstrated, even if the data was moved to CMOS
it would still be attackable, just differently.
Another problem would occur if the ROM were to "glitch", how would maintenance
be performed ? A BIOS "switch" could be added, but we have these available in
BIOS now from a few vendors, but the general public does not demand it. Also
maintenance can take many forms: about once a week I boot from a floppy to
perform defragmentation, backup, & compression since some of the 121k of TSRs
loaded high are incompatable with this kind of operation (one of the first
additions to DISKSECURE was the ability to create a boot floppy for this
reason) and most users do not want to have to rename their CONFIG.SYS &
AUTOEXEC.BAT before rebooting.
It has been stated that ROM could be inexpensive. True, in production quantity
the cost is less than a dollar, but take a look at BIOS upgrades with much less
code than MS-DOS that are holding at about $70 for the two-chip set.
The point has been made that MBR infectors such as the STONED would become
obsolete since the MBR and supposidly the Boot Record would become mere
tables. However, in this case, the first executable becomes CONFIG.SYS instead
of the MBR. We would just see a "new" breed of infectors - like many "new"
viruses today just a few changes would be necessary.
Of course, it would depend on the implimentaion also, just to use the STONED
again, the fact that it is so widespread has nothing to with any MS-DOS
requirement: MS-DOS does not "require" hidden sectors, all versions will run
without any. Yet most MBR & Boot Record viruses depend on them because they are
usually there. If they weren't, the method used by the earlier BRAIN and
attempted by the MusicBug would be much more widespread.
Again: there is nothing basically wrong with MS-DOS (and DR-DOS) that has
caused the incredible spread of viruses other than the total lack of
integrity checking, something that can be easily corrected in the BIOS or
by a BIOS extension. Putting MS-DOS in ROM will not itself reduce the risks,
it will just transfer some holes for others while necessarily leaving most
wide open.
Warmly,
Padgett
Only a third of a good program's code is needed to accomplish its function
the other two-thirds is to accomodate user's mistakes.
ps very few viruses actually change any executable code belonging to DOS
the common ones just change pointers that must be alterable to point to
themselves or map themselves into executed volatile storage locations
by reading (or knowing) the pointers. - app
------------------------------
Date: Fri, 24 May 91 13:13:11 -0400
From: padgett%
[email protected] (A. Padgett Peterson)
Subject: DISKSECURE 95 (PC)
To those of you who have requested copies, I had wanted to get it out
this week since Ken was nice enough to send the source to XXENCODE
*however* my Fiero developed a cold in the alternator (the first
symptom was when I took the key out of the ignition, the A/C blower
kept running - try troubleshooting THAT).
Having never seen the alternator, I consulted the service manual which
told me where it was & to remove wires, two bolts, & the fan belt then
"remove from bottom". Right.
Also disconnect engine strut, rear suspension, remove right rear
wheel, assorted brackets, splash shields, & the oil filter, mostly by
feel. At 2 a.m. I saw the alternator. Just like writing software.
In any event, am now a little behind & with the Muscle Car Nationals
just up the road a bit this weekend, will probably not get to it
before Monday but the requests are all in my "todo" bin. RSN.
Warmly,
Padgett
"Somewhere West of Orlando"
------------------------------
Date: 25 May 91 09:02:39 +0000
From:
[email protected] (Fridrik Skulason)
Subject: Re: "Horse" Virus Family (PC)
I wrote:
>> Horse (Hacker, Black horse) family:
William Walker C60223 x4570 writes:
>To further reduce naming confusion, might I suggest calling this
>family the "Hacker" family ("Hacker-1," etc.) to avoid confusion with
>Trojan Horses.
I considered this, but decided to use the name "Horse" instead - the
author, Martin Harizanov, uses the handle "The Horse", and there is
already another virus known as "Hacker" (alias "Ohio") as well as one
known as "Superhacker" (alias "Jerk"). Using "Hacker" would just
increase the confusion, instead of reducing it.
- -frisk
------------------------------
Date: Sun, 26 May 91 15:23:47 -0400
From: Alex Lopez-Ortiz <
[email protected]>
Subject: Delta virus (PC)
More than 50 of oour PC's (at the National University of MExico) have
caught this virus who alters the partition table of the hard disk,
trashes files that were to be saved, disallows booting from the hard
disk, and copies itself or generates a file called Delta<trash>.com
which is hidden and unerasable.
Does anybody knows of any vaccines against it?
Alex
------------------------------
Date: Thu, 23 May 91 11:54:27 -0700
From:
[email protected] (Rob Slade)
Subject: Review of SafeWord Virus-Safe (PC)
I believe there was a recent announcement by Bob Bosen of version 2.0,
but he has had this review for over a week now and I haven't heard
anything back.
Comparison Review
Company and product:
Enigma Logic Inc.
2151 Salvio Street, #301
Concord, CA 94565 USA
Tel: (415) 827-5707
FAX: (415) 827-2593
Internet:
[email protected]
SafeWord Virus-Safe release 1.12 (900831)
Summary:
Change detection software.
Cost: not stated
Rating (1-4, 1 = poor, 4 = very good)
"Friendliness"
Installation 3
Ease of use 4
Help systems 3
Compatibility 3
Company
Stability 3
Support 2
Documentation 2
Hardware required 4
Performance 3
Availability 2
Local Support ?
General Description:
SafeWord (R) Virus-Safe 1.12 is a manual or TSR program file checking
package based upon signatures which the program calculates when
installed. Signature algorithms can include a DES or MAC based
calculation. Enigma Logic makes similar programs for various mini and
mainframe operating systems. As suggested by this association and the
documentation, Safeword is best used in a managed environment. The
package is, however, simple enough to give significant protection to a
naive user.
[Ed. Due to its size, the remainder of this review has been placed in
the anonymous FTP archives on cert.sei.cmu.edu (IP#=128.237.253.5) in
pub/virus-l/docs/reviews under the filename slade.virus-safe]
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 90]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253
