Handbook of Infosec Terms 2.0/Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso/text/virusl/vl04_089.txt

Internet Message Format | 1996-09-04 | 23.0 KB

From:       Kenneth R. van Wyk (The Moderator) <[e-mail]>
Errors-To: [e-mail]
To:       [e-mail]
Path:      cert.sei.cmu.edu!krvw
Subject:   VIRUS-L Digest V4 #89
Reply-To:  [e-mail]
--------
VIRUS-L Digest   Thursday, 23 May 1991    Volume 4 : Issue 89

Today's Topics:

re: Tequila virus (PC)
re: MS-DOS in ROM? (PC)
Chinese Bomb (PC)
Virus-l archive et al
Anti-viral approaches (PC)
Re: Tequila virus (PC)
PKZ120.EXE trojan? (PC)
"Horse" Virus Family (PC)
RE: MS-DOS in ROM; RE: Software Upgradable BIOS (PC)
re: PKZ120.EXE trojan? (PC)
Re: Into the 1990s
Unidentified virus? (PC)
Re: Into the 1990s (ref IBM-type PCs)
re: Product Test, Flu_Shot+ (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 [e-mail] (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: [e-mail].

   Ken van Wyk

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

Date:    Wed, 22 May 91 17:19:17
From:    microsoft![e-mail]
Subject: re: Tequila virus (PC)

>From:    "David.M.Chess" <[e-mail]>

>While I know what you mean, Ross, I'd like to clarify for our readers:
>the Tequila doesn't actually seem to share any code with the 1260 or
>Virus-101 (no evidence that the author of the Tequila had seen either
>of those), and a scanner that can handle variable-length "don't care"
>areas can detect it with no problems.  DC

Whoops!  You're write! I should right better and knot make so many
misteaks! :-)

I have an abhorrence for wild-carded scan strings -- too many false
positives -- so I tend to not include them.  I ended up going
algorithmically on the Tequila in any case...

Ross

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

Date:    Thu, 23 May 91 09:54:00 +1200
From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: re: MS-DOS in ROM? (PC)

[e-mail] (Padgett Peterson) writes:
>>From:    "Krishna E. Bera" <[e-mail]>
>
>>Is there any effort underway to produce a ROM version of MS-DOS...
> Not that I am aware of though several laptops have attempted this.

yes there is; DRDOS 5.0 has been ROMable for about a year, and it
seems MSDOS 5 will available in ROM as well. It is a good idea (even
though I doubt it was planned as an anti-virus measure), but there are
some popular simple virus methods it won't help against. The great
benefit would be, I think (I haven't actually tried it though):

(a) Viruses that change not the interrupt vector but substitute a jump
at the start of the original code would be stopped, as would viruses
that change specific locations inside specific versions of DOS to hook
in virus code.

(b) Viruses that modify executables (assuming all DOS utilities are in
ROM)

(c) Viruses that add new .COM files with the same name (assuming all
directories in the path, and the current dir, are in ROM also)

(d) Boot Sector & MBR viruses (again, with reasonable assumptions
about the implementation)

What this leaves is a few loopholes like blatently reducing the TOM or
changing interrupt vectors, that are relatively easy to spot.

> The major problems would be:
> 1) Hardware is always more expensive than software to produce

The cost of ROM chips is amazingingly cheap - most motherboards have
empty ROM slots. Even if it needs an extra card with some fancing
hardware for paging in and out large amounts of ROM (a la EMS), the
cost of the card is likely to be small compared with modern costs of
operating system software. The problem is that most people don't "see"
the cost of the DOS because it is either lumped in with the cost of
the hardware, or pirated.  Software in ROM can be cheaper because the
manufacturer doesn't need to charge more to get over half of the users
not paying for the product.

> 2) Would make it difficult to upgrade

So long as it is a good product, like MSDOS 3.3 or DRDOS 5, people
tend to stick with one version of operating system for a long time -
long compared with the time before they wish they had a newer BIOS,
for example. This is true for enough people to make it worthwhile;
besides, the cost of the chips is very very small (say $10).

> 3) Would provide no protection from viruses - too many popular programs
>    and peripherals rely on tailoring the BIOS (e.g. hard disk controllers)
>    MBR (e.g. FDISK), and DOS (most TSRs) in approved methods. Unfortunately
>    many of these methods can also be used by malicious software.

The MBR need only contain the partition table - it need never be
executed. A TSR or virus can't make "sneaky" hidden changes to DOS,
they must result in obvious effects like changes to vectors, memory
allocation, etc. The only worry would be a virus that targets specific
TSR's.

> 4) Undocumented necessities (such as necessary to use a CD-ROM or NETWARE).
> 5) "Bug" fixes would be much more expensive.

You would want to change the DOS fairly infrequently, but I dodn't see
a big problem there. Perhaps some Digital Research bod could answer
how CD-ROMS or NETWARE work in the ROM version of DRDOS, but I guess
such things are possible.

Of course, another option would be for a 386 CPU to manage memory so
that it is as good as ROM - or possibly better (with IO trapping?),
except for the time while it is loading the DOS, and so vunerable. In
fact, a virus that makes full use of a 386 to protect itself would be
very worring - perhaps enough added to teh BIOS to protect that stage
would be the answer.

Mark Aitchison, Physics, University of CAnterbury, New Zealand.

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

Date:    Wed, 22 May 91 10:53:27 -0500
From:    Larry Anta <[e-mail]>
Subject: Chinese Bomb (PC)

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

........................................................................
: Larry Anta, Data Security Officer     Toronto Ontario CANADA M5B 2K3 :
: Ryerson  Polytechnical  Institute     Voice- [phone] Ext 6797 :
: Room S-341    350 Victoria Street     Bitnet-ADMN8621@RYERSON        :
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

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

Date:    Thu, 23 May 91 12:43:25 +0100
From:    David.J.Ferbrache <[e-mail]>
Subject: Virus-l archive et al

As a few of you may have noticed the archive service at Heriot-Watt
University is no longer operational. This is due to a lack of disk
space in the Computer science department, coupled with a change of
employment on my part.

From mid-July I will be leaving Heriot-Watt University to begin a new
job which includes a remit to evaluate the security threat posed by
computer viruses and to implement a range of suitable protective
measures. This should permit me to take a far more active (and
hopefully informed) role in this mailing list.

My apologies for any inconvenience caused by the temporary closure
(Again!!)  of the archive site. Back soon.

Dave Ferbrache

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

Date:    Wed, 22 May 91 17:19:17
From:    microsoft![e-mail]
Subject: Anti-viral approaches (PC)

>From:    Padgett Peterson <[e-mail]>

>For basic protection, almost all of the anti-viral software on the
>market is adequate, just like few people take more than basic
>protection from being stung by a wasp. More is considered
>contra-productive & is an accepted risk in working in a garden. When
>it happens, it is annoying but remedies are at hand.

If everybody made backups, I'd be out of business.

>To me, seven people stand out in this area ...
>... not because they are necessarily wonderful people, meetings can
>be explosive, but because they have made available to the public
>information and programs specificaly designed to combat viruses as
>shareware/freeware, not the best way to squeeze the last dollar out of
>the public.

Hey, I *am* a wonderful person, too!  Now, I'm currently trying to
squeeze as much money from the public as possible.  Fortuneately, I
code better than I market...

Ross

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

Date:    23 May 91 10:56:12 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: Re: Tequila virus (PC)

>From:    microsoft![e-mail]
>
>Sorry: I don't count "wild card" strings as a search pattern.  There's
>too much chance for false positives.  But, true, if you don't mind the
>occasional false positive, I guess you could state that a search
>string was available for Tequilaa.

A string with wildcards isn't necessarily more prone to false
positives than one without, as long as there are enough additional
fixed bytes in the one with wildcards to make up for the extra degrees
of freedom added by the wildcards.  I think?  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...

DC

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

Date:    Thu, 23 May 91 10:37:40 -0400
From:    Padgett Peterson <[e-mail]>
Subject: PKZ120.EXE trojan? (PC)

>From:    <[e-mail]>

There was a "hacked" PKZ120 a few months ago. The one I recollect was just
PKZ110 with the names & authentication codes changed. I would be surprised
if a real version 120 exists (expect Mr. Katz will skip that number)

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

Date:    23 May 91 11:07:00 -0600
From:    "William Walker C60223 x4570" <[e-mail]>
Subject: "Horse" Virus Family (PC)

Fridrik Skulason ( [e-mail] ) writes:
> The names below are the names Virus Bulletin will use in the next issue,
> where the viruses are listed - hopefully this list (which I plan to post
> monthly) will help reduce the naming confusion a bit.
> ...
> Horse (Hacker, Black horse) family:
>    Horse-1 (1154)
>    Horse-2 (1158)
>    Horse-2B (1160)
>    Horse-3 (1610)
>    Horse-4 (1776)
>    Horse-5 (1576)
>    Horse-6 (1594)
>    Horse-7 (1152)
> ...

To further reduce naming confusion, might I suggest calling this
family the "Hacker" family ("Hacker-1," etc.) to avoid confusion with
Trojan Horses.  Some people refer to Trojan Horse programs simply as
"Horses" instead of Trojan Horses or Trojans.

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

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

Date:    23 May 91 11:08:00 -0600
From:    "William Walker C60223 x4570" <[e-mail]>
Subject: RE: MS-DOS in ROM; RE: Software Upgradable BIOS (PC)

Padgett Peterson <[e-mail]> writes:
> Subject: re: MS-DOS in ROM? (PC)
> The major problems would be:
> 1) Hardware is always more expensive than software to produce

Definitely.

> 2) Would make it difficult to upgrade

I'm not so sure.  If the 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.).  As it is now, upgrading DOS
on a hard disk involves doing SYS and copying COMMAND.COM and the other files
to the hard disk.  Also, as I have found too many times, users have copied
some of the DOS programs all over their drive rather than one location, and
following a DOS upgrade, they call in with an "Incorrect DOS version" error.
Swapping cartridges would be quicker and easier, and would eliminate
"straggler programs."

> 3) Would provide no protection from viruses - too many popular programs
>    and peripherals rely on tailoring the BIOS (e.g. hard disk controllers)
>    MBR (e.g. FDISK), and DOS (most TSRs) in approved methods. Unfortunately
>    many of these methods can also be used by malicious software.

It would provide SOME protection from viri, in that the DOS files themselves,
being in ROM, would be immune from infection.  Also, since the remainder of
the BIOS is also in ROM, it is immune as well (I'm aware of peripherals adding
BIOS extensions, but not "tailoring" the existing BIOS).  However, once in
RAM, anything is fair game, and other program files on disk would not have the
benefit of ROM protection.

> 4) Undocumented necessities (such as necessary to use a CD-ROM or NETWARE).

Items such as CD-ROMs have ROM BIOS extensions and/or drivers loaded by
CONFIG.SYS.  DOS in ROM would not affect their operation, so long as the boot
process accessed the ROM extensions and used a user-modifiable CONFIG.SYS and
AUTOEXEC.BAT.  However, non-DOS executables stuck in CONFIG.SYS and
AUTOEXEC.BAT would still be prone to infection if run from a disk.

Netware, on the other hand, is a different puppy.  Netware in ROM would be
impractical, since it would have to be customized to each specific
configuration, and there is a HUGE variety of configurations.  I suppose it
would be possible to produce a Netware kernel in ROM, but because so much
configuration-dependent stuff would be left in software, it would probably
be better to leave it all in software.

> 5) "Bug" fixed would be much more expensive.

Yes, indeed.  But if DOS in ROM was on a handy cartridge, containing
UV-erasable PROM, the old cartridges could be returned after an upgrade or
bug-fix to be erased and reused by the manufacturer, thereby reducing costs.

He also writes:
> Subject: Software Upgradable BIOS (PC)
> ...
> if the hardware designers do their job. A EEPROM requires a special signal
> on one lead to tell it to write. If that lead is under hardware control and
> accessable only with the case open and a special plug in place that disables
> everything except a "load & verify BIOS" program, risk can be minimal.

Exactly.  If the BIOS upgrade is tied to hardware control of some kind, then
there's little problem.  If it's COMPLETELY under software control, however,
what's to prevent a virus author from writing a virus which can simulate a
software BIOS upgrade?  The whole idea that Intel has is to eliminate the
need to open the case or do some complex hardware operation.  A ROM
cartridge still seems to be the better way to go; besides, how many times
does one upgrade the BIOS during the life of a machine?

> The point is not to "protest" the concept, it sounds like a good idea, but
> demand adequate safeguards (dare I say "standards") for its use.

OK, so I was a bit extreme.  But we do need to DEMAND those safeguards or
a more secure alternative.

> ("flew" some digitally controlled gas-turbine engines with  8080s at
> Tullahoma in the seventies - Hi Bill)

Everybody sing - "It's a Small World after all." :-)

These are, of course, ideas and opinions, and are subject to comment,
criticism, or whatever.

Bill Walker ( [e-mail] ) | "If you were locked in a room with
OAO Corporation                        |  Saddam Hussein, the Ayatullah, and
Arnold Engineering Development Center  |  a lawyer, but you had only two
M.S. 120                               |  bullets, which would you shoot?"
Arnold Air Force Base, TN  37389-9998  | "I'd shoot the lawyer twice."
( somewhere near Tullahoma )           |

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

Date:    Thu, 23 May 91 10:45:00 -0600
From:    Keith Petersen <[e-mail]>
Subject: re: PKZ120.EXE trojan? (PC)

SIMTEL20 does not now, and never has offered PKZ120.EXE.  That file is
bogus and PKWare has offered a reward for information leading to the
person or persons responsible for its creation.

This is very old information.  There has been a warning in circulation
about this for almost a year.  It was posted to the net.

The latest version of the program is:

Directory PD1:<MSDOS.ZIP>
 Filename   Type Length   Date    Description
==============================================
PKZ110EU.EXE  B  140116  900402  Katz's ZIP archive package v1.10, export vers.

This file was obtained directly from PKWare on diskette.

Keith
- - -
Keith Petersen
Maintainer of the MSDOS, MISC and CP/M archives at SIMTEL20 [192.88.110.20]
Internet: [e-mail]    or     [e-mail]
Uucp: uunet!wsmr-simtel20.army.mil!w8sdz              BITNET: w8sdz@OAKLAND

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

Date:    Thu, 23 May 91 12:38:42
From:    microsoft![e-mail]
Subject: Re: Into the 1990s

>From:    Y. Radai <[e-mail]>
>
>  Among Ross Greenberg's points in his reply last week to Padgett
>Peterson was the following:

>>...[my discussion on FLU_SHOT+'s integrity checking]

>  Sorry, but I just can't pass over that without comment.

Oh.  It's *you* again.  <grin>  Just when I thought it was safe to go back
into the water.  <theme music to _Jaws_ in the background>

>  (No offense meant, Ross, but I'm sure it won't come as a surprise to
>you if I mention that in my opinion, a good example of poor product
>quality despite presumably good sales figures is the integrity-check-
>ing feature of FLU_SHOT+.  But since I've discussed FSP enough in the
>past, I won't repeat my arguments unless someone asks.)

To paraphrase your past arguments for the readership, I believe you commented
that FSP's installation was such a pain in the butt that few people used
the integrity checking feature FSP includes.  You're probably right there,
by the way.  I would hope that *quality* of the product is not an issue.
We might have some disagreements as to whether "fast 'checksumming'" is
better or worse than "complex 'checksumming'", but that's a good debate
to have in September during the Virus Bulletin's Seminar -- over a coupla
beers, I hope.  (Hey! Could you bring me a bottle of Macabee? Love it, can't
get it here.  Bring one for Ken, too!)

Quality is an issue that the market does decide, I think. Effectiveness is
something that may or may not be related to marketshare.  But the market
does not buy low-quality products (unless it comes from my competetion,
of course. :-) ).  They may end up buying slicker *quality* products
than less slick quality products, though.

>>Resident integrity checking, and access control, is a worthy goal of
>>any of the anti-virus products. However, remember that it can and
>>*will* be circumvented the first time somebody boots off a floppy.
>
>  That does not have to be true; details in a couple of weeks.

This I look forward to hearing more about.  Typical security that would
prevent this would be either a)playing with the partition record, easily
circumvented by a decent disk editor or b)encryption of the disk to
prevent circumvention of a).  I thought about crypting the disk and
realized that I couldn;t afford the liability insurance.....

Another option would be in hardware, one I'm starting to think more and
more carefully about...

L'itrot

Ross

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

Date:    Thu, 23 May 91 10:37:40 -0400
From:    Padgett Peterson <[e-mail]>
Subject: Unidentified virus? (PC)

>From:    [e-mail]

>This rebooting continued even when I was in Norton commander..

>I turned the system off and on again.. There were No problem at the
>beginning.. But after 30 minutes( or so) It started rebooting as if
>the reset button is pressed..

Sounds to me more like a marginal power supply. Try opening the case
and running for a while and see if it changes (afer a thorough virus scan
of course). 30 minutes seems to be a critical "warm-up" time when a power
supply starts getting tired.

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

Date:    Thu, 23 May 91 10:37:40 -0400
From:    Padgett Peterson <[e-mail]>
Subject: Re: Into the 1990s (ref IBM-type PCs)

>From:    Y. Radai <[e-mail]>

>>Resident integrity checking, and access control, is a worthy goal of
>>any of the anti-virus products. However, remember that it can and
>>*will* be circumvented the first time somebody boots off a floppy.

>  That does not have to be true; details in a couple of weeks.

Also agree with Mr. Radai. Hardware can block completely & software can detect
(but not necessarily block) a cold floppy boot & changes. Both can control hot
boots - <cntrl><alt><del>. Both the hardware and the software exist but
apparantly lack proper marketing (in defernce to Mr. Walker, development
funds are finite & can be spent on marketing or development. Rarely
is it split 50-50 [more like 100-0]).

Will state again: Effective systems MUST start before DOS loads & do not have
to be intrusive.

                    Warmly,
                        Padgett

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

Date:    Thu, 23 May 91 12:38:42
From:    microsoft![e-mail]
Subject: re: Product Test, Flu_Shot+ (PC)

>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>

>.  The commercial firm is now Microcom Software Division which
>markets Virex-PC.  While Mr. Greenberg actually sold Microcom Flu_Shot++, not
>Flu_Shot+, I was somewhat surprised when version 1.81 reached the repository i
n
>December 1990.  This version came bundled with a demonstration copy of the
>viral scanning capability of Virex-PC.  Subsequent electronic communications
>with Mr. Greenberg suggest that Microcom may view continued releases of
>Flu_Shot+ as a commonsense marketing strategy to migrate users to their
>commercial product.

Yeah, FLU_SHOT++ got renamed to Virex-PC.  I happen to *still* like
the name of FLU_SHOT++ more, but offer me enough money and... <grin>

Chances are good that future releases of FLU_SHOT+ (You're falling
behind, Chris: Version 1.82 is out the door) will *not* include the
bundle of the VIRX scanner.  Bundling them together meaks it difficult
to release one without the other and can create some auditing
nightmares.  Additionally, looking at people downloading from my BBS,
everybody seems to download both the FLU_SHOT+ archive (which contains
VIRX) *and* VIRX.

By unbundling, the download time will be lessened (important on pay
services) and the ability to update each independently of the other is
enhanced.

Microcom's permission to allow me to continue to enhance and release
FLU_SHOT+ is a credit to their marketplace acumen, I think.

Ross

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

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