VIRUS-L Digest Friday, 31 May 1991 Volume 4 : Issue 94
Today's Topics:
Re: Software Upgradable BIOS (PC)
What is DOD?
Re: Interesting advert (PC)
Re: VIRUSSUM format (PC)
noint virus (PC)
Re: MS-DOS in ROM (PC)
F-Driver.SYS and QEMM (PC)
Network World Article (PC)
Re: Tequila virus (PC)
Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.)
re: FSP and sales figures (was: Into the 1990s)
AIDS Information Trojan (PC)
re: Addendum to FLU_SHOT+ Product Test (PC)
re: In the past year... (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, 30 May 91 13:24:00 +1000
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),"
> [bits deleted]
> It does make sense to simplify the BIOS field upgrade, but to do it
> using something as transient as software in this day and age probably
> would not be wise. More logical would be a small cartridge, not
> unlike an HP font cartridge, which can be changed without having to
> open the case. Sure, it would be more expensive up front, but
> compared to the possibility of a "BIOS resident" virus, it would be
> much less expensive overall. The same type of thing could be used for
> a ROM-based DOS cartridge, which could have a switch that selects
> booting from cartridge or disk, much as Krishna E. Bera suggests.
I have to agree that software changeable BIOS is a scarey thought, but
an alternative to the 'catridge' idea would be the imposition of a
hardware switch which permits BIOS writing. The update program could
request the user to 'Press the button marked BIOS and hold it down
until the update is finished.'
Probably not as reliable as the 'BIOS cartridge', but still, it is a
thought.
Danny
------------------------------
Date: Thu, 30 May 91 16:07:36 -0500
From: Mac Su-Cheong <
[email protected]>
Subject: What is DOD?
Dear Netters
May someone please give me information on DOD Computer Security Center ?
Is it possible to get reports or papers of DOD ?
Thanks in advance.
MSC
- ---
Mac Su-Cheong
nckus089@twnmoe10
[email protected]
------------------------------
Date: Thu, 30 May 91 15:52:00 +0300
From: Y. Radai <
[email protected]>
Subject: Re: Interesting advert (PC)
Kenny Stevenson writes:
>Just read an interesting ad in Personal Computer Magazine, April 1991
>VNU 404, page 135. It seems that most of us can now sleep easy if the
>claim made in this advert is true - what will all you EXPERTS do ?!
....
>Vaccine anti-virus system - "Vaccine is virus-non specific detection
>software. It uses cryptographic checksums to monitor the state of
>executables on a PC or file-server. Any change, however caused will
>be detected. Since Vaccine does not need to know about particular
>viruses in order to detect them, it is future proof. Once installed,
>Vaccine will detect all viruses, past, present and future."
....
>Comments welcome ! (and I can't imagine that there woun't be some)
There is absolutely nothing new in this ad. There are zillions of
checksum programs for the PC which claim to do the very same thing.
However, there are three things to note: (1) They cannot distinguish
between an actual viral infection and (say) replacement of an old
version of a program by a new one; this is left to the user to decide.
(2) The vast majority of such programs cannot really catch *all*
infec- tions because DOS has loopholes which the authors of these
programs are unaware of. (3) This method only *detects* infections
after they have occurred; it does not prevent or remove them, so
there's still a wee bit left for the "experts" to do.
Actually, there is one such program, V-Analyst, which goes a long
way toward solving all three problems: (1) It can distinguish between
the above two situations in *most* cases. (2) It checks for three
loopholes and takes the necessary measures. (3) It contains a
*generic disinfector* which, when a modification is detected, will
attempt to restore the file to its original condition. If the
modification is due to a virus, it can do this in the great majority
of cases (regard- less of whether the virus is known or unknown).
Moreover, there is never any danger of its performing an incorrect
restoration. (Features (1) and (3) are available only in the new
version 3.0, not yet offi- cially released.)
I'm willing to bet that Vaccine doesn't come anywhere near this.
Padgett Peterson to Kenny::
>Question: when does it go resident ? If from CONFIG or later, you know
> my opinion.
Answer: Who says a checksum program has to go resident at all?? Most
checksum programs I know of (incl. Vaccine and V-Analyst) can (or
must) be run without going resident.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Thu, 30 May 91 11:36:37 -0400
From: padgett%
[email protected] (Padgett Peterson)
Subject: Re: VIRUSSUM format (PC)
Mikael Larsson <
[email protected]> writes:
> > 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.
>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.
For what its worth, the individual virus files in PCVI305 are in
ASCII, it is the selector/viewer that is a program.
Since I automatically filter VIRUSSUM and reformat with form feeds
after each listing so that it goes into a loose leaf easily, I have
felt for some time that this would be nicer and allow "updates"
monthly rather than having to download/print the whole thing each
month. Telco fees can add up.
The only problem with such a flat file arrangement (access can be very
fast) is that it takes up a lot of disk space (200 viruses @ 2k per
cluster = 400k - smaller on floppy of course).
The big thing to remember is that VIRUSSUM is copyrighted material and
Patricia has put a lot of effort into it. Her decision on whether it
exists at all is final.
Warmly,
Padgett
------------------------------
Date: Thu, 30 May 91 11:50:00 -0500
From:
[email protected]
Subject: noint virus (PC)
If anyone has info on the noint virus I'd appreciate a copy. I do
remember one posting recently, but I did not keep it. thankyou in
advance.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Darrell G. Leavitt
SUNY Empire State College (ESC) ESC VAX: DLEAVITT
403 Sibley Hall SUNYNET: SESCVA::DLEAVITT
Plattsburgh, New York, 12901 INTERNET:
[email protected]
PHONE : (518) 564-2837 AMATEUR
BitNet : LEAVITDG@SNYPLAVA PACKET: N2IXL @ KD2AJ.NY.USA.NA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Thu, 30 May 91 11:47:13 -0400
From: padgett%
[email protected] (Padgett Peterson)
Subject: Re: MS-DOS in ROM (PC)
"William Walker C60223 x4570" <
[email protected]> writes:
>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 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.
While I follow the premise better now, what you are talking about is
what I referred to in the third option - somehow swapping ROM
addresses for RAM addresses or possibly a "page frame" approach such
as used for expanded memory. It will take a special BIOS driver to
accomodate just like a RAM-disk requires a special driver and the data
areas will have to stay resident somewhere. The point is that there
are a finite number of addresses available and if some are used for
ROM then there are that many less for RAM unless some extra memory
management scheme is used such as that used for "shadow RAM" on 386s -
not difficult but requires a few extras.
The point I was trying to make was that even with this type of
mechanism, the same holes exist in MS-DOS as did before. Some have
been moved (e.g. the first attackable point) so that specific
malicious software will be thwarted, but the hole still exists and
will just be exploited in the next crop. There is still NO integrity
management in MS-DOS.
Warmly, Padgett
------------------------------
Date: Thu, 30 May 91 09:02:00 -0800
From:
[email protected]
Subject: F-Driver.SYS and QEMM (PC)
Yesterday I re-optimized my memory allocation on a Zenith 386-SX
because it had lost 2K of memory. As it ran through the process, the
Stoned virus was detected, and the system froze, as it should have.
However, the station had been used on and off several times since its
infection, with no detection by f-driver.sys (ver 1.15A), and I
suspect that the reason for this is that it had been loaded into high
RAM by QEMM when running OPTIMIZE. I do not recall reading anything
about this in the F-PROT documentation.
[email protected]
------------------------------
Date: Thu, 30 May 91 15:08:14 -0600
From:
[email protected] (Richard W Travsky)
Subject: Network World Article (PC)
The May 27th Network World has a nice article on viruses and
networks/lans. It talks about how viruses have progressed from an
annoyance to a major problem (surely news to everyone here), quoting a
study by Certus International where 50% of 2500 selected sites (with
400 or more micros) had reported problems with viruses.
Lans are stated to be a major conributor to the spread of viruses.
The section of the article of some interest to me was a test of 21
virus scanning packages conducted by the NCSA. An accompanying chart
shows the percentage of detection by the packages against 921 viruses.
Here's how the rankings went (only 15 of the 21 were reported for some
reason):
Package Percentage of Viruses Recognized
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
F-Prot V. 1.14A 92%
Sophos, Ltd. Vaccine V. 4.23 91%
Solomon Software Toolkit 4.25 89%
Thijssen HTScan 1.12 78%
Thijssen HTScan 1.11 73%
McAfee Assoc. Pro-Scan V. 2.01 73%
Symantec Corp. Norton AntiVirus V. 1.0.0 72%
WorldWide Software, Inc. Vaccine 3.0 70%
Microcom, Inc. VPCScan V. 1.1A 69%
IBM VirScan V 1.3 66%
EliaShim Microcomputers ViruSafe 3.06/7 63%
McAfee Assoc. Pro-Scan V. 1.4 62%
Certus International Corp. V 2.1 61%
EliaShim Microcomputers Inc. ViruSafe 3.05 57%
IBM VirScan V 1.0 25%
Hopefully there are no typos. I just report 'em, the interpretations
are your job.
Some of these packages I've never heard of.
Towards the end of the article they spend a few paragraphs talking
about SiteLock and its virus protection features for lans.
Richard Travsky
Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming (307) 766 - 3663 / 3668
------------------------------
Date: Thu, 30 May 91 17:20:01
From:
[email protected]
Subject: Re: Tequila virus (PC)
>From:
[email protected] (Morgan Schweers)
> However, what I meant by
>'psuedo-encryption' is a situation in which the METHOD is different
>each time. For example, the Tequila uses XOR *OR* ADDitive
>encryption. This is more than one form of encryption, so in referring
>to the entire group I call it psuedo-encryption. The same with the
>Whale, etc. It could also be called variable encryption if you wish.
Hmmm. Interesting definition. I use "variable encoding" to indicate
that something in the virus is designed to thwart scanners: variable
"NOP" type instructions, that kinda stuff. I use "encryption" to
indicate that the code has been mangled in some form, regardless of
how many methods a given program uses. That would make Tequila a
"variable encoding encrypted" virus, I guess. Pain in the butt, in
any case.
> Actually, if you are using five bytes to search for the virus,
>and someone else is using 15 (interspersed with a few wildcards), is
>it automatically to be assumed that the wildcarded one is going to be
>less specific? Do you have any statistics behind it?
That is too obviously backwards to require stats and is not what I was
implying. Of course having 16 bytes with no wild cards *should* be
more specific that 16 bytes with wildcards.
> There is also a second trick, used by some. When the file is
>detected as almost certainly being a virus, the decryption method is
>used on a portion of the file. That portion is compared against a
>standard, known block of code. If a match ISN'T made, the file is
>ignored.
Yeah, we use that for 1260 and Caspar and a coupla others. Another
pain in the butt, frankly. Maybe I'm just getting burned out in the
anti-virus arena and would rather be scuba-diving... <g>
Ross
------------------------------
Date: Thu, 30 May 91 17:53:09
From:
[email protected]
Subject: Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.)
>From:
[email protected] (Morgan Schweers)
>
> Goodness, the personality conflicts alone [in the AV field]
>would make for an
>wonderful novel, then we add in the hysterics of the commercial side
>of the business... 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. *grin* Other patrons
>diving for cover, and huddling behind tables suddenly. Yupyup... For
>an industry this size, there's been a lot of backstabbing and
>slandering, etc.
Morgan, your drinks are on me at this bar! You've certainly said a
mouthful. I'm amazed at the animosity between the various people in
the field. To our credit, the majority of "outsiders" think we're all
good buddies.
Ross
------------------------------
Date: Thu, 30 May 91 18:23:56
From:
[email protected]
Subject: re: FSP and sales figures (was: Into the 1990s)
>From: padgett%
[email protected] (A. Padgett Peterson)
>>... 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.
If the seed is entered by the user, then there might well be problems
of getting "pre-installed" copies within an organization that al share
the same seed. Just as an example: one site license on FLU_SHOT+
pre-installed it on about 300 machines. Just by chance the installer
was running DOS 4.01 on his machine, everybody else was running DOS
3.3. Obviously, the checksums on the system files and COMMAND.COM
were different and I got umpteen tech support calls on the "problem".
Now, this was a major problem because of installation done beforehand.
Imagine my problem if each checksum was altered slightly with a
different seed? Unless they tell me the seed (or I play games to
derive the seed), I have a major tech support problem.
And if they have the seed stored on the system anywhere -- sorta
required in order for it to work! -- then the bad guy can find it just
as easily as my own code can. It buys the end user nothing, in my
opinion, but causes a major support headache.
Hey! Didn't I say that on the other side of the album or last year?
>Anti-Viral software should now be in its third generation:
>1) Initial design
>2) Take care of exceptions & annoyances
>3) Make it "user-friendly"
Actually, I think each of those phases are sorta endless loops. Lots of
changes in the next cut of my code due to enduser feedback, responding
to competitors, etc.
>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.
If you want RACF on a PC, you'll have to change operating system, I
think. It looks like you're speaking of authenticity and access
control -- these must be considered important *parts* of an anti-viral
package. But not the whole thing.
>I will make a stab at some targets:
Forgive me if I "stab" you back? <g>
> 1) Simple to install - should only give user opeions that are based on
> the machine in question.
Pre-installed products will have a problem as mentioned above. Many sites
don't want to install each package individually on individual machines.
> 2) Should recognize incompatable products
Once advised, sure. Until then...how does one know? This will always
be a one-version-off problem.
> 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
See the compatability problem you mention above. A bug has to be fixed
and not all compatability problems can be determined at release time. As for
virus scanners: my first product in the arena used a brute force method
of scanning, back when I had about 50 strings. I have about 500 now. The
same technique would have you waiting ten times longer. One method was quite
appropriate a year ago, a different one now. Once DOS 2.x ruled the earth,
but lots of dinosaurs get extinct. Upgrades are required in many cases, says
this mammal.
> 4) Each machine should have a different algorithm if only a unique seed.
See above.
> 5) Must make provision for routine mainenance (defrag, etc.) while
> maintaining functionality
Difficult to maintain system integrity there while doing "dangerous" things,
though. But agreed.
> 6) Must be easy to remove for troubleshooting
Hey, *my* code never needs to be removed! <grin>
> 7) Must recognize ANY change and be smart enough not to bombard the user
> with notices when authorized.
Should be user selectable, allowing a sys admin (even on a PC!) to determine
just how "loud" an alert should be.
>Unfortunately, I know of many mainframe packages that do not meet these
>criteria.
Yeah, RACF. Remember: this is not your father's Oldsmobile...
Ross
------------------------------
Date: Fri, 31 May 91 00:40:44 -0700
From:
[email protected] (McAfee Associates)
Subject: AIDS Information Trojan (PC)
Does anyone recall whatever happened to Joseph W Popp, the alleged
mastermind behind the AIDS Introductory Information Trojan Diskette?
Apparently he was arrested in late February or early March of 1990 on
charges of extortion and blackmail, but I have not heard anything
since. Was he convicted? Were the charges against him dismissed?
If anyone could mail a reply it would be appreciated.
Aryeh Goretsky
McAfee Associates Technical Support
------------------------------
Date: Thu, 30 May 91 17:53:09
From:
[email protected]
Subject: re: Addendum to FLU_SHOT+ Product Test (PC)
From: Chris McDonald ASQNC-TWS-R-SO <
[email protected]>
>ADDENDUM for Product Test PT-27, May 1991, subject: FLU_SHOT+
> Several days after transmitting PT-27 for FLU_SHOT+ the author
>sent me an electronic message, also posted to Virus-L, informing me
>that version 1.82 was now available. The author also advised me that
>the "free" demonstration copy of Virex-PC would no longer be included
>with FLU_SHOT+.
Actually, to be more specific, it will merely be removed from the .ZIP
file. It will still be available for download from my BBS and from
other sites -- including SIMTEL-20, since I'll be loading it to Keith
directly henceforth. And, please, take the quote from the word
"free"? It really is free - it merely forces you to wade through some
screens of advertising.
It will still be distributed on the disks of registered FLU_SHOT+
owners.
> While I was aware that a version 1.82 was available, I chose
>to limit my comments to version 1.81 because I had access to it
>through simtel20. As mentioned in the product test analysis, I have
>never received any official notification of FLU_SHOT+ upgrades even
>though I am a registered user. While INTERNET is usually faster than
>U.S. postal channels, it was not fast enough in this instance.
I'm working on simulataneously releasing code to SIMTEL-20 along with
other sites so that this confusion doesn't happen again. As for
postal notification: please send me your snail mail address for
confirmation? If I'm sending out 50K+ pieces of mail, I'd sure like
to make sure that they're actually being received!
> The "free" Virex-PC demonstration is now available at many
>locations to include simtel20 in the path:
Thar ya go again with them quotes, dagnabit! It really is free. No
hidden charges, no auto-decrement on your wallet or anything.
> I apologize for any inconvenience.
Me, too.
Ross
------------------------------
Date: Thu, 30 May 91 18:23:56
From:
[email protected]
Subject: re: In the past year... (PC)
>From: "David.M.Chess" <
[email protected]>
Microcom tech support in Virex-PC reports:
1. Stoned
2. Jerusalem (with varients)
3. Disk Killer/Ogre (yeah, surprised me, too!)
4. Joshi
5-10. Cascade, Fumanchu, Sunday (yeah...see 2., above), Yankee (and varients)
Ping Pong, Ghostballs.
My own tech support for FLU_SHOT+ shows:
1. Jerusalem (with varients)
2. Stoned
3. Joshi
4. Ping Pong
5. everything else.
Ross
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 94]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253
