VIRUS-L Digest   Thursday, 30 May 1991    Volume 4 : Issue 93

Today's Topics:

VSUM Format (PC)
Re: Hard Disk R/W errors (PC)
Re: Software Upgradable BIOS
re: FSP and sales figures (was: Into the 1990s)
Re: Chinese Bomb (PC)
Followup to my STONED problem (PC)
In the past year... (PC)
Wildcards (Was: Re: Tequila virus) (PC)
Re: Question About Stealth Viruses
Re: MS-DOS in ROM; Re: NVMs (PC)
Re: Hoffman Summary & FPROT (PC)
Re: Virus-Buster (PC)
virii vs System 7.0 (Mac)
Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.)

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, 29 May 91 15:55:27 +0200
From:    Mikael Larsson <[email protected]>
Subject: VSUM Format (PC)

Posting this message from a friend that will soon get an own account!
*****
> From:    [email protected]
>
> 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.

I disagree with this because that means that You can only access the
database on a given computer platform. The VIRUSSUM.DOC should remain
in pure ASCII given the benefits of being able to read it from
whatever machine your using.

If the demand rises someone will write a program to access
VIRUSSUM.DOC on any platform, just as I am currently doing for the
PC:s with my VSUMBROW program.

Regards /Jonny Bergdahl
FidoNet: 2:204/503
VirNet : 9:463/101
BBS: +46-36-121323
Virus-L Digest => VirNet echogate

Rgds,

MiL
        Virus Help Centre            Phone    : +46-26 100518
        Box 7018                     Fax      : +46-26 275720
        S-81107  SANDVIKEN           BBS      : +46-26 275710 (HST)
        SWEDEN                       FidoNet  : 2:205/204
                                     VirNet   : 9:461/101
                                     SigNet   : 27:5346/108
                                     Email    : [email protected]

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

Date:    29 May 91 14:20:32 +0000
From:    [email protected] (Richard Hempsey)
Subject: Re: Hard Disk R/W errors (PC)

[email protected] (Schwegler Ralph) writes:
>     Hello,
>
>     When i first switch on my computer, my HD (Seagate SR-238) works well.
>     But after some minutes, there are many R/W errors. I am using DOS 3.21;
>     i have low level formated my HD as a SR-238R HD, with Seagate's
>     Diskmanager.
>
>     I could not find a virus, either with f-prot 115 or scan 77. If i list
>     the TSR, there is a 3120 bytes long file labelled ?.
>
>     Could that be the cause of the harddisk problems ?
>
>     Thanks for your advices.
>
>     Ralph Schwegler, student at University St.Gallen for Economics (CH).
>     E-Mail : [email protected]  /  [email protected]

The problem might simply be thermal expansion of the platter in the
drive.  As the drive warms up, the platter expands, and the heads are
now mis-aligned.  I had the same problem with my Miniscribe 8438.  A
very simple cure: I never turn my computer off! Well, except for
thunderstorms...  If you have to turn the computer off, then boot from
a (clean, of course!) floppy, and wait for the computer to warm up
before using the hard drive.

Suggestion: Buy a copy of Spinrite II and use it regularly. Best $80 I
ever spent. (I am in no way affiliated with Gibson Research, just a
satisfied customer)

Richard Hempsey   at   [email protected]
                 or   [email protected]
                 or   ...!alberta!aunro!ersys!nowhere!rich
- -----------------------------------------------------------------------
"If my theory of relativity is proven successful, Germany will claim
me as a German... Should my theory prove untrue... Germany will declare
that I am a Jew." - Albert Einstein

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

Date:    29 May 91 08:15:00 -0500
From:    "William Walker C60223 x4570" <[email protected]>
Subject: Re: Software Upgradable BIOS

Vergil William de Comyn ( [email protected] ) writes:

> 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.

It's good to know that they are tying the BIOS upgrade to hardware in
some way.  One interesting feature of this would be that knowledgeable
users could make BIOS patches rather simply; and it would make bug
fixes easier.  One drawback would be that pirating of the upgrades
would be easier, which may end up making the upgrades more expensive.
I still think there's too much inherent risk in it (my opinion), and
would prefer a ROM BIOS (also my opinion).

Also, I find fault in the logic behind one of the reasons for making
an upgradable BIOS: "to get the full benefit of a CPU upgrade" (no, I
don't find fault with the benefit itself -- read on).  This is in
reference to the newer machines which have a replacable CPU on a
little card.  Glenn Henry, Dell's VP for marketing, says, "You can run
your old 386 BIOS with a 486 upgrade card, but you'll pay a
performance penalty unless you install a fully coded 486 BIOS." If
you're gonna have the case open to replace the CPU, how much trouble
would it be to replace the ROMs while you're at it?  For that matter,
why not design the replacable-CPU system so that the BIOS is on the
replacable card, to automatically upgrade the BIOS too?  Cost
shouldn't be a factor, since compared to the cost of the machine and
the CPU upgrade itself, a ROM BIOS upgrade would be inexpensive.

One last thing before I shut up.  I wrote:

> >                            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).

and Jeroen. W. Pluimers <[email protected]> wrote:

> From what I understand this is quite common, most ROM BIOS
> manufacturers use EEPROMS which can be repogrammed when you have:
> a) the new EEPROM image (on disk or as an (EEP)ROM)
> b) and EEPROM programming device that can program that kind of EEPROM
> c) a very strong UV lamp to erase a programmed EEPROM

EPROMs are erased by UV light and are programmed from disk or ROM with
a programming device.  EEPROMs ( ELECTRICALLY erasable programmable
ROMs ) are not UV-erasable, and a programming device is not used to
program them (normally).  They are erased by a signal on one of the
leads, and are reprogrammed in place in the circuit.  EAROMs operate
similarly.  That's the whole idea behind Intel's plan -- to reprogram
them in place in the PC from software, to save having to remove and
replace them.

Anyway, I've said probably more than my share on this, so I'll hush
("...and there was much rejoicing."  -- Monty Python)

Bill Walker ( [email protected] ) |
OAO Corporation                        |
Arnold Engineering Development Center  |  AEDC -- Home of the "Chicken Gun"
M.S. 120                               |
Arnold Air Force Base, TN  37389-9998  |

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

Date:    Wed, 29 May 91 12:32:46 -0400
From:    padgett%[email protected] (A. Padgett Peterson)
Subject: re: FSP and sales figures (was: Into the 1990s)

>From:    [email protected]

>... it should give different
>"seeds" for each system.  I recall that discussion and that I felt
>(and still feel!)  it's a good idea, but a tech support nightmare.

Doesn't have to be, Enigma-Logic's product uses a different "seed" for
each machine that is entered once by the user at installation time &
is never encountered by either user or tech again.

Also, about a year ago, we discussed a matrix method for a sinple checksum
algorithm to be produced on the fly.

>Not quite.  However, a real dog of a product that simply doesn't work
>is, eventually, gonna be found out and will have zero sales volume.

The hooker here is "eventually". Besides, few products don't work at
all and the first indication the poor sap who bought it may not come
until he gets hit by something that is not caught or a manager finds
out what it costs to update the software periodically on 5000 PCs.

Anti-Viral software should now be in its third generation:
1) Initial design
2) Take care of exceptions & annoyances
3) Make it "user-friendly"

but, except for those who are very deep into the subject, it is difficult
to determine the "exception" cases and which products have the third
generation look but skipped the second. I know of at least five software
packages and several BIOSes & disk controllers that will give a good
integrity checker fits (second generation problems) but have not seen
any advertising by anti-viral products that give me a "warm" feeling.

In the last month, I have returned two different Windows word processors
to their respective manufacturers, one because it thought WordStar 4.0
was the last version (5.0 came out in 1988), another because the driver
I had to use for my Panasonic printers (Windows doesn't list any
Panasonics) caused the second to produce pure gibberish on the screen.
These are second generation problems.

>It's tough to decide on what determines the relative quality of a
>product, though: if a scanner does 500 viruses and scans your disk in
>two minutes and another scanner does 600 viruses and scans your disk
>in three minutes, which one is a "better" product? Does making it
>pretty, with a cool/spiffy GUI make it a "better" product?

Consider quantum economics: first the process must be "good enough". Then
linear comparisons become important. A minute is lost in the noise to a
tech checking out a problem. If it occurs every time a user loads a file,
it is liable to be noticed.

To me "good enough" is a product that will detect any change to a system
or authenticated file that is unauthorized without flagging. At the same time
actions that are authorized for a product will be passed without challenge.
I haven't seen any yet though some come close.

I will make a stab at some targets:
 1) Simple to install - should only give user opeions that are based on
    the machine in question.
 2) Should recognize incompatable products
 3) Should be robust enough not to require program updates unless new
    features are added. Simple data files updates of new signature strings
    should be all that is necessary
 4) Each machine should have a different algorithm if only a unique seed.
 5) Must make provision for routine mainenance (defrag, etc.) while
    maintaining functionality
 6) Must be easy to remove for troubleshooting
 7) Must recognize ANY change and be smart enough not to bombard the user
    with notices when authorized.

Wish list: program privilege (e.g. rwe) interpreted and enforced by the
program manager. Unknown programs have no privilege. Disk access enforcement
is easy. Memory access enforcement is more difficult (but possible with 386
or good memory manager hardware).

We will probably not be there until every new program is distributed on
non-volatile media (e.g. notchless floppies) with authentication documentation,
certification that what was received was what the manufacturer meant to send
out, and a list of specific permissions the package requires.

Unfortunately, I know of many mainframe packages that do not meet these
criteria.



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

Date:    29 May 91 17:21:40 +0000
From:    [email protected] (Michael Nolan)
Subject: Re: Chinese Bomb (PC)

[email protected] (Larry Anta) writes:

>The following message appeared on one of our IBM PCs:

>                          VP    9z     U(    5/

>                   ----  C h i n e s e    B o m b   ----

>                          ( Made in China  1989 )


>C:\WORD>
>C:\WORD>

>According to one of our technicians, the hard disk was "trashed" at
>that point.  (He says he had to format it.)

>Any help would be appreciated.  (McAfee's SCAN V75 comes up clean.)

There was a story on the radio this morning about a 'BEIJING' virus,
set to go off on the 2nd anniversary of the Tienimen Square Massacre.
The story went on to imply that this virus is on hundreds of thousands
of computers all over China.  (I didn't know there *were* hundreds of
thousands of computers in China...)  Is this related?

Michael Nolan
[email protected]

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

Date:    29 May 91 13:40:36 +0000
From:    [email protected] (Harry Pulley)
Subject: Followup to my STONED problem (PC)

Last night I used scanv72 on my floppy (the one that gave me the
famous message in the first place).  It was in the boot sector!  I had
heard that scanv76 was buggy, but I thought that STONED was an old
enough virus that it would still be able to detect it.  Oh well, a few
hours were wasted scanning floppies with v76 -not a big loss.  I will
take home a copy of v77 today.

N.B. this system was at home, not in a gov't building (we only run
UNIX in my project, so I don't think we have the right to use
scan/clean/etc...).

Thanks for any replies, I'm still interested in the way that STONED
works.

[Ed. There's a great description (IMHO) of the Stoned virus available
for anonymous FTP on cert.sei.cmu.edu.  The file name is
stoned.descript.lawrie and it is in the pub/virus-l/docs directory.
The description was written by Mike Lawrie
([email protected]) - Thanks Mike!]

Harry.

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

Date:    29 May 91 14:59:55 -0400
From:    "David.M.Chess" <[email protected]>
Subject: In the past year... (PC)

Below is a list, in roughly descending order, of the PC-DOS viruses
that we've actually seen in real-life incidents in the past year (to
eliminate "one-off"s, and try to get just the important ones, I've
only listed the ones that we've seen and verified in at least three
incidents over the past year; this technique of data-reduction is open
to modification!).

I'd be very interested in similar lists from other folks, especially
if there are significant differences.  The population that we see
reports from, as we've said before, is heavily weighted towards
Fortune-500 companies and suchlike, but has some of everything.  I've
only counted incidents in which we were able to get a sample and
verify (by hand, or with a CRC-based automatic verifier) that it
really was that virus; I'm not counting "I've heard that Wuga is
widespread in the Arctic" or "my cousin ran a virus-scanner, and it
said he had the GaBooo virus, so he formatted his hard disk" sorts of
reports.  (I'd appreciate it if other folks who are kind enough to
make their lists available would indicate whether they're using
similar standards for what to count.)

Here are ours.  28 different viruses (I've folded together the 1813
and one tiny variant of it, that we call 1813-00).  Note that the
slope is very steep here; the Bouncing Ball accounts for fewer than
one-third as many incidents as the 1813.

  Stoned (Marijuana)
  1813 (Jerusalem)
  Bouncing Ball (Ping-Pong)
  JOSHI
  Yankee Doodle-2885 (TP44VIR)
  1701
  4096 (Frodo)
  1704
  Sunday
  Dark Avenger
  Vacsina (TP05VIR)
  TP16VIR
  Slow
  Form
  Brain
  Keypress
  Flip-2153
  Plastique (Anti-CAD)
  Disk Killer
  1575
  Microbe
  Liberty
  Yankee Doodle-2772 (TP39VIR)
  5120 (VBASIC)
  Ohio
  Anarkia
  1381 (Internal Error)

Is everyone else seeing similar things?

DC

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

Date:    29 May 91 21:21:02 +0000
From:    [email protected] (Fridrik Skulason)
Subject: Wildcards (Was: Re: Tequila virus) (PC)

David Chess wrote:
 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...

Ross Greenberg wrote:
 We'll have to agree to disagree on this one, Dave.

Well, tend to agree with David - I use wildcards in 15% or so of my
search patterns - but only in the following cases:

1) When the pattern contains a reference to an address outside it.
  Example:

               :
               MOV AX,CS:[some_address_elsewhere]
               :
       or
               :
               JNE a_fairly_long_distance
               :

2) When the pattern contains an instruction which depends on the assembler
  used - Example:

       XOR AX,AX       ; 31 C0
       XOR AX,AX       ; 33 C0

I have some variants of viruses where the only difference is due to this.

Variable-length wildcards are in my opinion an absolute no-no...I never use
them.  For the viruses using the most complex types of encryption (Whale,
Tequila, V2P2 and Adolph) I use an algorithmic approach, not a search string.

I also try to avoid search patterns for viruses written entirely in a
high-level language.

- -frisk

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

Date:    29 May 91 21:34:02 +0000
From:    [email protected] (Fridrik Skulason)
Subject: Re: Question About Stealth Viruses

[email protected] (Robert McClenon) writes:
>    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?

To qualify as a "stealth" virus a virus must:

       A) Make any increase in file length disappear when a user checks
          an infected file while the virus is active.  Viruses which
          do not change infected files ("companion viruses") are not
          included, nor are overwriting viruses.  The "Number of the
          beast" virus is considered to be a stealth virus.

       B) Intercept any operation to read from an infected file or
          an infected boot sector, and make the virus code "disappear"
          by returning the original program.  Whether this is done by
          actually disinfecting programs when they are opened for
          reading, or just by modifying the read buffers is irrelevant.

According to this definition, "Brain" is a stealth virus, for example.

> I have read that they delete themselves from the hard disk and hide in
> memory when they are active.

Totally incorrect.  Some "stealth" viruses disinfect programs when
they are read, so it is possible to remove them by simply giving a
command like

                       COPY *.* NUL:

in every directory containing executable files, but this is certainly
not an universal solution.

- -frisk

Fridrik Skulason                 Technical Editor of the Virus Bulletin (UK)
(author of F-PROT)               E-Mail: [email protected]    Fax: 354-1-28801

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

Date:    29 May 91 16:10:00 -0500
From:    "William Walker C60223 x4570" <[email protected]>
Subject: Re: MS-DOS in ROM; Re: NVMs (PC)

A. Padgett Peterson ( padgett%[email protected] ) writes:

> ...
> 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.
> ...

and I wrote

> ...
> If the [ MS-DOS in ] ROM upgrade is on a cartridge (similar to HP
> fonts), upgrading would involve swapping cartridges, which could also
> contain the other DOS-related files (CHKDSK, EDLIN, etc.).
> ...
> It would provide SOME protection from viri, in that the DOS files
> themselves, being in ROM, would be immune from infection.
> ...

We're writing from two different premises.  Padgett is writing about
MS- DOS actually running from ROM, while I'm writing about the DOS
files, and the boot disk itself, being in ROM ( a ROM-disk, as opposed
to a RAM-disk ).  The method of running MS-DOS from ROM, as Padgett
states, is currently used by some laptops, and also by some diskless
LAN- stations and third-party boot cards.  The method of booting from
a ROM- disk ( with an infection-proof boot sector and system files ),
which I wrote about, is not implemented at this time, to the best of
my knowledge.

Mr. Peterson and I are not arguing the point ( at least I hope not;
sorry if it seemed that way, Padgett ), but we're presenting two
different answers to the same question.  Each method has its
advantages and disadvantages, and each may be applicable in different
situations.  Since this may indeed be an ongoing discussion, I thought
it necessary to point out the differences in our solutions.

Oh, BTW, Michael A. Maxim ( [email protected] ) writes:

> If some board maker actually
> wanted to enable software modification to the BIOS EEPROM, there is no
> reason that he couldn't do it; but that is a problem with the board
> and manufacturer, not the chips.

I had originally questioned the security of using EEPROMs and a
software- upgradable BIOS, not the EEPROMs themselves.  I had merely
used Intel's announcement as a starting point for my discussion, and I
apologize if I seemed like I was being critical of the chips or the
technology.

Bill Walker ( [email protected] ) |
OAO Corporation                        | "Non sequitur -- your facts are
Arnold Engineering Development Center  |  un-coordinated."
M.S. 120                               |           -- NOMAD
Arnold Air Force Base, TN  37389-9998  |

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

Date:    29 May 91 21:38:47 +0000
From:    [email protected] (Fridrik Skulason)
Subject: Re: Hoffman Summary & FPROT (PC)

[email protected] (Richard W Travsky) writes:
>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.

Due out in just a few days..actually - as soon as I have finished
analysing the 100+ new viruses I have received the past couple of
weeks.

>Any reason why such an old version is used?

Well, I wish I knew - I always send her the latest versions...

- -frisk

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

Date:    Wed, 29 May 91 22:18:55 +0000
From:    [email protected] (Andrew Turner)
Subject: Re: Virus-Buster (PC)

[email protected] (Trieu B Phan) writes:
>   Has anyone ever used that(Virus-buster).
>   It seems strange to me,I have installed it on my PC and after I
>reboot the PC is hang,I have to use a bootdisk to turn on.
>   Any ideas,please drop me a line.

While this is not a 'plug' for Virus Buster I am concerned that such a
simple statement as above could be seen as negative for what is, among
the several anti-viral packages on the market, a basically good
product.  Furthermore Leprechaun Software, who market Virus Buster,
are very approachable and will readily assist all users.  I note that
the poster is a down under person and thus can readily avail himself
of this facility. FLAME OFF.

Each of the anti-virals has its pros and cons - none are a 'complete'
solution.  We successfully use Virus Buster on student access PC's and
are most happy with the results. DISMOUNT SOAPBOX.

I will e-mail Triu B Phan and see if he can be helped.

- --
Andrew Turner  [email protected]
       Die, v: To stop sinning suddenly.
                       -- Elbert Hubbard

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

Date:    Wed, 29 May 91 20:19:11 +0000
From:    [email protected] (Geoff Bronner)
Subject: virii vs System 7.0 (Mac)

I recently had the pleasure of working with a hard disk running under
System 7.0 which had been infected with the nVir A and B viruses.
Disinfectant was able to remove the viruses without any problems once
another disk was used as the startup disk.

What was interesting to note however was what had been infected.
Several applications including Microsoft Word had been infected (which
is not surprising) but so had several Control Panels. Under the new
system cDevs and DA's and such can be accessed like applications and
it appears the nVir viruses are fooled into infecting them like
applications as well!

One other note. The virus was caught with a regular check and the
workstation had shown no unusual behavior so nVir didn't appear to be
causing problems.

Has anyone else observed this kind of behavior under System 7.0?

- -Geoff

- --
       [email protected]
       Alpha Theta House Historian
       "Don't believe the hype!"
               -Public Enemy

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

Date:    Wed, 29 May 91 12:32:46 -0400
From:    Padgett Peterson <padgett%[email protected]>
Subject: Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.)

>From:    [email protected] (Morgan Schweers)

>Of course, a fictional bar scene with all the
>principal players would be...frightening.  I picture these ten people
>suddenly realizing who else is at the bar, and the temperature
>dropping twenty to thirty degrees suddenly.

Doubt it, I recall a bar in SEA in which automatic weapons had to be checked
at the door, handguns were OK.

>    (A side and sad note...  It is not us, the anti-viral researchers,
>who will kill the viruses once and for all.  It's the OS writers who
>will finally produce an OS which supports the protections a machine
>needs.  It's the users who will finally leave this damned MS/DOS
>troublemaker behind.  THAT is when viruses will vanish, slowly but
>surely, and then we can all have a beer together and laugh about the
>nonsense of having to clean up behind Microsoft.)

Unlikely that DOS will disappear, it is too much a part of the culture, just
like the English language and SAE screw threads.

However, nothing is stopping DOS from introducing anti-viral measures and
self-checking boot sectors & MBRs. The key is in preservation of the
applications and hardware. It is just not going to be in 5.0.

                                       Warmly, Padgett

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

End of VIRUS-L Digest [Volume 4 Issue 93]
*****************************************

Downloaded From P-80 International Information Systems 304-744-2253

You are viewing proxied material from infinitelyremote.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.