VIRUS-L Digest Tuesday, 9 Jul 1991 Volume 4 : Issue 119

VIRUS-L Digest Tuesday, 9 Jul 1991 Volume 4 : Issue 119

Today's Topics:

Re: Words
Re: vscan() - Virus and hack resitance (Warning!)
Virus simulations - a bad idea ? (PC)
HTSCAN15, TBSCAN28, TBSCNX29, VS910630 uploaded to SIMTEL20 (PC)
Re: Can such a virus be written .... (PC)
Re: Software pricing
Encoded strings
Re: DOS 5.0 & FPROT116 (PC)
Re: Demo Disk from Mainstay (Mac)
Re: DOS 5.0 & FPROT116 (PC)
Stoned virus and DIR command (PC)
re: Self scanning executables (pc)
re: PC Plus (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: 05 Jul 91 20:33:09 +0000
>From: [email protected] (Johnathan Vail)
Subject: Re: Words

[email protected] (Rob Slade) writes:

[email protected] (Johnathan Vail) writes:

> virus - a piece of code that is executed as part of another program
> and can replicate itself in other programs. The analogy to real
> viruses is pertinent ("a core of nucleic acid, having the ability to
> reproduce only inside a living cell"). Most viruses on PCs really are
> viruses.
>
> worm - a program that can replicate itself, usually over a network. A
> worm is a complete program by itself unlike a virus which is part of
> another program. Robert Morris's program, the Internet Worm, is an
> example of a worm although it has been mistakenly identified in the
> popular media as a virus.
> bomb.

Question:

Given that under these definitions boot sector infectors, "spawning"
viri and items such as Mac's WDEF are excluded from "virus", does that
make them all "worms"?

If so, you will have to define "most viruses on PCs", since many of
the more successful PC viri are BSI's.

Unless I am misunderstanding how these work I would still classify them
as viri since they "infect" already existing useful code and depend on
those programs being executed before the virus code can get an
execution thread.

I am open to suggestions on wording and mistakes I may have made. I
plan on posting a revision soon with the comments and additions I have
recieved.

jv

"Imagine what it would be like if TV actually were good. It would be the end
of everything we know." -- Marvin Minsky
_____
| | Johnathan Vail | [email protected]
|Tegra| (508) 663-7435 | [email protected](WorldNet)
----- [email protected] {...sun!sunne ..uunet}!tegra!vail

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

Date: Sat, 06 Jul 91 07:33:03 +0000
>From: [email protected] (Morgan Schweers)
Subject: Re: vscan() - Virus and hack resitance (Warning!)

[email protected] sas:
>[email protected] (Eric Vaitl) wrote:
>}
>} Earlier, I sent out a net posting with some code that was in
>}error. Here is the is the (hopefully) correct code. When added to your
>}own programs, I believe it will make them virus and hack resistant. Any
>}feedback would be appreciated.
>
>I hate to burst your bubble, but your code is essentially useless
>against viruses. The only viruses it would catch are the few which
>indiscriminately clobber executables, and those are very easy to spot
>anyway (the program stops working once infected). Most viruses attach
>themselves such that they get control first; before passing control to
>the original program, they remove any changes made to the beginning of
>the executable and then jump there. As a result, these viruses leave an
>unmodified memory image. To self-scan itself, a program must go out to
>disk and read the executable file, not memory.
>
>On the other hand, your function will work just fine to detect someone
>going in and modifying one or more bytes of the program's code.

Greetings,
Thanks Ralf! I'll say pretty much the same thing... Plus a few
suggestions. The code posted has *NO* effect on almost any viruses.
It will catch hacks, but if someone is playing with a debugger on your
program, they can bypass that too.

As a *PERSONAL* recommendation (this is *NOT* an official
recommendation) I would suggest looking at the MKAWARE (aka AWARE)
program. It looks to be a solidly useful piece of code. As I recall,
it should be available under Simtel20... As to *WHERE*, I don't know.
Try looking at the Index.

(Or you could call archie and look for 'aware')

It does a CRC check on the file that was executed. The only
drawback to this involves Stealth viruses. These are viruses which
hide themselves before executing your program. These will not be
caught by *ANY* checksumming or CRCing system, nor any scanning system
unless any one of those three are run from a known clean,
write-protected system disk. However (and thankfully) these are not
common.

Obviously, it will not protect against BSI's (Boot Sector
Infectors) either, but those aren't necessarily dangerous to the
program you are releasing.

As a side comment, please PLEASE note in your documentation that
your program is self-checking. The reason for this is that the
program may come up with an alarm when a third-party validation code
is added. Often problems like this can be headed off by warning the
user in the first place that the program checks itself.

Furthermore, I'll point out that length-checking is not always
that good an idea. If a file is transmitted via XMODEM or sometimes
even YMODEM, it gets padded to a length divisible by 128. This means
that the filelength expected is no longer accurate.

As a result, of course, full file checksums/CRCs may not work either.

This is another reason to use archiving programs! (These problems
never should happen with any archiving programs, since the correct
size is always stored.)

All in all, it's good to see people taking an active interest in
protecting their programs from the development stage on. If more
people (can you say MickySoft? I knew you could!) took this
viewpoint, I'd be happily out of a job. *grin*

I love my job, but I really don't like the things which caused it
to come around. That being viruses.

-- Morgan Schweers

P.S. Actually, in all honesty, MicroSoft has been reasonably intelligent
in it's self-checking on occasion. (See MS Word.) It's just too bad
that it's not implemented more across the board, and it's also too bad
that there aren't reasonably *SOLID* file protections, like most
operating systems have. I look towards DOS 6.0 with hope, but not
expectations.
- --
[email protected] | Morgan Schweers | Happiness is the planet Earth in your
[email protected]| These messages | rear view mirror. -- Jeff Glass
Kilroy Balore | are not the +--------------------------------------
Freela | opinion of anyone.| I *AM* an AI. I'm not real...

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

Date: Sat, 06 Jul 91 13:48:08 +0000
>From: [email protected] (Fridrik Skulason)
Subject: Virus simulations - a bad idea ? (PC)

I recently got an E-mail message from Doren Rosenthal, the author of a
virus simulator program. It seems he has written a program which
generates files which contain various signature strings from various
viruses.

He asked me if I would provide him with a list of the signatures I
use. As I find his program totally useless, and capable of doing more
harm than good I refused.

My reply is included below, but I would like to hear others opinions
on virus simulators, in particular this one.

- -frisk

- ------------------------- reply to Mr. Rosenthal.

Well, I am sorry to disappoint you, but frankly I don't think your
virus simulator is a good idea at all.

Even if you included the signatures from my virus scanner, which I am
not willing to give to you, this would not guarantee that my scanner
would detect your "simulated" viruses. At least my 'Quick' scanner
would not find any of them unless the signatures were located at the
correct location in the file, and my 'Full' scanner would report each
file as infected by a new variant.

The major reason I do not think the program is a good idea is the
total inability to handle non-signature based scanners. Algorithmic,
and in particular hash-method scanners will not detect anything in the
files.

And in fact, I don't care if my program detects your "simulated"
viruses or not. My scanner is designed to detect real viruses, not
simulations.

- -frisk

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

Date: Fri, 05 Jul 91 17:21:10 +0200
>From: [email protected] (Jeroen Pluimers HB304 tel. 4298)
Subject: HTSCAN15, TBSCAN28, TBSCNX29, VS910630 uploaded to SIMTEL20 (PC)

I have uploaded to SIMTEL20:

pd1:<msdos.trojan-pro>
HTSCAN15.ZIP HTScan virus scan v1.5; needs VSyymmdd.ZIP
TBSCAN28.ZIP Thunderbyte Virus Scan 2.8; needs VSyymmdd.ZIP
TBSCNX29.ZIP Thunderbyte XScan v2.9 TSR; needs VSyymmdd.ZIP
VS910630.ZIP Virus Signatures for TBSCAN(X)/HTSCAN - 910630

Jeroen W. Pluimers
[email protected] (Sun SPARC station IPC, Sun OS 4.1.1)
[email protected] (VAX 3400, VMS 5.4)

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

Date: Mon, 08 Jul 91 11:37:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <[email protected]>
Subject: Re: Can such a virus be written .... (PC)

[email protected] (Matthew F Ringel) writes:
> [email protected] (Pete Lucas) writes:
>>until the virus has had a look at whats there. Of course the write-protect
>>notch/slide is 99.99% effective in my experience at preventing any
>>illicit writes; you would, of course, have write-protected any diskette
>>you put in the drive before doing the hypothetical DIR command, wouldnt
>>you?
>
> Speaking of that...
> Is it possible for a virus to circumvent an IBM's
> write-protection of a disk (if the disk is protected in the stndard
> way of covering the notch), or is it something physical that no piece
> of software can get around?
>
1. Remember that write-protect tabs on a diskette won't stop your computer
getting a virus from an infected diskette,
2. Yes, it is possible for a very special type of virus to infect your PC
when you do a DIR command; as was mentioned before, it is only possible
if you have ANSI.SYS loaded, and such viruses tend to be obvious - both
in terms of what goes on the screen and unusually long delays. I doubt
a "serious" virus writer would be any more keen to use this technique
than writing a virus in Interactive COBOL! (There are quite a few factors
stacked against such viruses succeeding, not the least of which is the
high chance of tracing back the actual floppy to its source).
3. The question of write-protection failing was thrashed out a while ago.
In summary: yes, some drives/diskettes/tabs fail to correctly protect
from writing. Not enough to have a virus base its existance on the
problem, and certainly nothing to do with anything the virus can control
(no loophole in the design, simply some photo-sensors pick up light when
they shouldn't). I've only come across one machine like that personally,
so you shouldn't lie awake at nights worrying. But you might like to TEST
your machine, and perhaps test new brands of diskette when they have some
tabs that seem significantly different to anything you've used before.
But probably the only people that will find such precautions useful are
those who deal with a lot of computers - e.g. a friend of mine works for
a computer maintence company, and has found he needs to test his write
protected diskettes regularly (because he works with MANY computers, some
are faulty in various ways, and the impact of his diagnostics diskettes
transferring infections to other clients is a worry, and yes, he did get
an infection on a write-protected disk once).

Mark Aitchison.

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

Date: Mon, 08 Jul 91 12:17:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <[email protected]>
Subject: Re: Software pricing

There needs to be both free and charged software; there are very good
reasons for having both...

(1) the computer-using public as a whole suffer from viruses. It would
help me if the majority of PC's had enough protection to stop or
detect the common viruses, to reduce the chances of an epidemic.
Avoiding a plague out there reduces the effort I need to make to
reasonably protect my own computer systems. I really think there
should be good software to do this, for free (preferrably built into
the operating system). In fact there is some pretty good software
already, but of course keeping up with the latest viruses is an
expense for those who produce it, and not knowing how well it performs
against new viruses (not rare ones though) is a worry for its users.

(2) Some people will always demand higher protection than others. For
most of us, it is enough to demand that (Cost of it
happenning)*(probability) is low, but there are some cases where you
really can't stand to have any virus, and that's not just on
life-support computers, but many "serious" systems, where it is worth
paying $30 for protecting a computer.

(3) The underlying problem with SCAN that was stated by an earlier
poster was that universities (for example) must obtain a site license,
i.e. pay for ALL machines to have the software, when the majority of
PC users will be in the first category, and only a minority in the
second. That's a separate question to "Is $xx per PC good value?".

(4) There should be a free database of virus information, available to
all users (and a-v writers), and it should try to standardise on
naming, etc. But whoever compiles it need not put the time into
analysing the viruses. I know this can take a lot of time and
therefore deserves financial returns. Instead, people could contribute
analyses, listings, etc to supplement the summary - in whatever form
they think will sell. Having a non-commercial, complete virus library
and free summary/identification system would help everybody; having a
compatible set of useful information (e.g. how to disinfect!) would be
worth money to many people, and that is where, to be fair, the
charging should come in.

Mark Aitchison.

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

Date: Mon, 08 Jul 91 06:30:06 -0700
>From: [email protected]
Subject: Encoded strings

[From: "zmudzinski, thomas" <[email protected]]
>> > As Ross [Greenburg] has pointed out, no matter how well strings are
> encrypted, eventually someone will break the code, and then it is a
> trivial matter to write a virus that circumvents that package.

should not go uncontested. This paraphrase contains two (mathematical,
not grammatical) infinitives, "no matter how well ... encrypted" and
"eventually". If I can play with one infinitive, let alone two, I can
probably prove the world is flat (well, it _is_, locally) or some such.
- -=-=

Of course . But, one point I implied but did not specificly state, is being
passed over altogether, here. That being:

That while most people who are writing Virus prevention/removal
routines are expirenced programmers, we make a large mistake when we
assume that the idiots are quite so expirienced. I would venture a
guess that a goodly portion of the virus idiots (The bad guys) would
be thwarted by any encryption above the trivial level.

You see, while I agree with Ross that :
>> The bad guys can certainly break
>> whatever coding scheme I use, thereby using the string list just as if
>> it were not encoded at all.

....I would submit that many of the different strains we've been
seeing are bad copies of the original code, often times being a simple
string change that one could have invoked using a disk editor, right
on the EXE or COM file, without ever seeing the source code.... thus
furthering the idea that much of what we see in the way of virus
programming (as opposed to anti-virus programming) is created by less
than expirienced programmers. Ouch! Run on sentences were my problem
all through school, too. Anyway, such people would be thwarted by
encryption out of hand, thus significantly reducing the amount of
viral strains in the wild.

Standard disclaimers apply.

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

Date: Mon, 08 Jul 91 12:40:00 -0400
>From: "Ignorance HATES Knowledge..........!!" <[email protected]>
Subject: Re: DOS 5.0 & FPROT116 (PC)

>A user recently posted this on our BBS. Has anyone else experienced this?
>
>"I was wondering if any one has experienced a problem with FPROT116.
>Since I installed it with msdos ver 5.00 it hangs my system with the
>message Virus Alert!! Int 13 has been changed. I have tested and no
>virus is found. If I disable f-driver in my config.sys file everything
>is ok. All other programs associated with this program works fine. Any
>thoughts or suggestions?"
>
>I am not familiar enough with FPROT116 or DOS 5.0 to make an
>intelligent comment. Any help will be appreciated.
>
>- -- Steve Clancy

Without getting into all the reasons why this was a problem.... The
way to fix it for me anyway... Was to boot from a floppy -- then erase
ALL the files the the SUBDIR -- \F-prot ...... I put them back from a
fresh disk then rebooted from the hard disk. Worked just fine.....

tell your user not to use the command LOADHIGH with the F-* TSRs as
it'll hang the system. The device driver will work fine with the
DEVICEHIGH command in the config.sys.

Sorry this is short, I'm sure someone else will provide a description as
to why this occurs -- I just wanted to get you an answer....

Bob Martin -- Eastern KY U. -- Academic Computing -- 606 622-1995
bitnet: Acsmartin@eku or graphics @eku

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

Date: Mon, 08 Jul 91 12:01:30 +0800
>From: [email protected]
Subject: Re: Demo Disk from Mainstay (Mac)

>Date: Wed, 03 Jul 91 20:58:05 +0000
>From: [email protected] (Rob Schaeffer)
>Subject: Demo Disk from Mainstay (Mac)
>
>The demo disk from Mainstay has nVIR attached to the archive. It
>seems to not be able to spread, but it is there.
>
>Disinfectant nicely removes the virus.
>
>I would be curious to know why the virus doesn't spread.

It could be that it is only an nVIR stem, put there to prevent nVIR from
actually infecting the file. It could also be the remnant of an incomplete
removal.
<->
Bruce Carter, Courseware Development Coordinator [email protected]
Boise State University, Boise, ID 83725 [email protected]
(This message contains personal opinions only) (208)385-1250@phone

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

Date: 08 Jul 91 13:19:11 +0000
>From: [email protected] (Ing. Alfredo Delgado Garza)
Subject: Re: DOS 5.0 & FPROT116 (PC)

[email protected] (Steve Clancy) writes:

A user recently posted this on our BBS. Has anyone else experienced this?

"I was wondering if any one has experienced a problem with FPROT116.
Since I installed it with msdos ver 5.00 it hangs my system with the
message Virus Alert!! Int 13 has been changed. I have tested and no
virus is found. If I disable f-driver in my config.sys file everything
is ok. All other programs associated with this program works fine. Any
thoughts or suggestions?"

I am not familiar enough with FPROT116 or DOS 5.0 to make an

I had the same troubles, i fixed it by puting the device=f-driver.sys
as the last line in my config.sys.

It looks like the SMARTDRVR.SYS takes the int 13 causing that message.

Alfredo Delgado.

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

Date: 08 Jul 91 14:51:00 -0500
>From: "William Walker C60223 x4570" <[email protected]>
Subject: Stoned virus and DIR command (PC)

1From: Mike Ramey <[email protected]>
> Discovered several grad students had diskettes infected with Stoned.
> Experiments confirmed that a DIR command on these diskettes caused
> Stoned to become resident in RAM. I do not know how or when Stoned
> moves to the fixed-disk partition sector/boot record.

IMHO, Stoned was already resident in RAM before executing the DIR
command. I ran the following test using a clean hard drive and a
Stoned-infected diskette in drive A:

SCAN C: /M
"No viruses found."
DIR A:
SCAN C: /M
"No viruses found."

However, the following WILL put Stoned in memory (though not really
active):

SCAN C: /M
"No viruses found."
DISKCOPY A: A:
SCAN C: /M
"Found Stoned Related Virus [Stoned] active in memory."

So will this:

SCAN C: /M
"No viruses found."
NU A:
[Norton Utilities 4.51 - look at boot sector, then exit by
pressing F10]
SCAN C: /M
"Found Stoned Related Virus [Stoned] active in memory."

This is due to the same problem with MS-DOS which caused the PRODIGY
scare and the abuse which was recently heaped upon Ross GreenbErg:
MS-DOS does not clear resources (memory or disk) before reusing them.
If you want it done, you've got to do it yourself. However, as
indicated by the first test, DIR does not load the boot sector into
memory in the first place. I would be interested in seeing your
results with a SCAN /M (or equivalent), DIR, SCAN /M sequence of
tests.

One interesting note: In an attempt to make a "defanged" version of
Stoned (with which to train users in using antivirus software), I
changed some disk write commands to disk resets and one CALL to NOP's,
and got this:
SCAN A: /M
"Found Azusa Virus [Azusa] in boot sector."
Are they really that close?

Bill Walker ( [email protected] ) |
OAO Corporation | "That's not a bug,
Arnold Engineering Development Center | that's a feature!"
M.S. 120 | - Anonymous
Arnold Air Force Base, TN 37389-9998 |

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

Date: 08 Jul 91 16:17:14 -0400
>From: "David.M.Chess" <[email protected]>
Subject: re: Self scanning executables (pc)

As I'm sure hordes of other folks will point out, Eric Vaitl's nice
little self-checker does *not* compute a CRC (as the comments say),
but only a simple add-em-up checksum. A CRC (Cyclic Redundancy Check)
is somewhat more complex than than, no?

Also, checking the memory image of the program isn't really the right
defense against viruses; most viruses restore the memory image to
normal before passing control to the infected program, so I think
programs incorporating this method will not actually notice the
typical virus infection. (Although I'm not entirely positive how
Turbo C does memory allocation, so I may be missing something there.)

Self-checks need to check the on-disk copy of the executable, not the
in-memory copy (and of course even then they are subject to fooling if
there's a stealth virus around).

A nice effort, though, and such idea-sharing is certainly a Good Thing!

DC

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

Date: Mon, 08 Jul 91 19:49:52 +0100
>From: [email protected]
Subject: re: PC Plus (PC)

I feel the need to respond to James Nash's advert for PC Plus, as none
of the British magazines have yet shown themselves reliable in
providing objective reviews of anti-virus software. I had hopes that
Personal Computer World might have been able to produce something, but
these disappeared when most of their best contributors left during the
management/ journalist union dispute of December 1989.

Most of the reviews I have seen have suffered from undisclosed interests.

Several considerations may have influenced Mark Hamilton's review in
PC PLUS:
* journalists don't generally maintain their own libraries of viruses for
testing, in this case the 100% detection rate of Bates Associates
product indicates that Jim Bates' virus collection was used.
* Hamilton writes for the Virus Bulletin; this publication is owned
by Sophos.
* RG Software has just been announced as the new distributor for the
Virus Bulletin in the USA.
* Microcom's Virex-PC is the commercial version of Flushot+, in one
edition that I saw the documentation included an acknowledgement from
the author of code contributed by Mark Hamilton.

I am not suggesting that Mark Hamilton has deliberately misrepresented
the products of these companies, but that these relationships should be
kept in mind when reading the review.

One error of fact is that Sophos's Sweep isn't "the only [anti-virus]
product in this country to have been granted a UKL1 certificate by the
Government's Computer and Electronic Security Group". PC Security's
Eliminator gained UKL1 certification earlier this year, as reported in
Virus Bulletin January 1991.

Declaration of interests: I work at Thecia System Ltd, we produce an
anti-virus product called Virus Clean, which was not invited for inclusion
in Hamilton's review.

Thanks for your time,
Anthony Naggs

(Reply to: [email protected] or phone me at Thecia Systems: 0273 623500)

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

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

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