|
Virus- L Newsletter V.6 No.35 From Internet
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
================================================================================
VIRUS-L Digest Thursday, 25 Feb 1993 Volume 6 : Issue 35
Today's Topics:
WARNING: Two new Mac viruses (Mac)
Re: Sale of Viri [sic]
your opinions on virus legality
polymorphic compiler
Re: general entertainment
Re: How to measure polymorphism
Detecting Michelangelo (PC)
Rebuilding partition tables (PC)
Re: EXE/COM switch (PC)
Effect of Form (PC)
Re: Michelangelo detect/removal instructions (PC)
Re: PC Magazine reviews virus scanners (PC)
Re: Scanning memory (PC)
Help - GenB and GenP virus problem (PC) (long)
Re: Question about Patricia Hoffman and John McAfee (PC)
Michelangelo Functions (CVP)
Re: Virus Survey Results
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. (The complete set of posting guidelines is available by
FTP on cert.org or upon request.) Please sign submissions with your
real name. Send contributions to [email protected]. Information on
accessing anti-virus, documentation, and back-issue archives is
distributed periodically on the list. A FAQ (Frequently Asked
Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5). Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<[email protected]>.
Ken van Wyk, [email protected]
----------------------------------------------------------------------
Date: Thu, 25 Feb 93 11:30:55 -0500
From: [email protected].edu
Subject: WARNING: Two new Mac viruses (Mac)
Two New Macintosh Virus Variants Discovered
25 Feb 1993
First Virus (variant): CDEF
Damage: as with CDEF
Spread: unknown
Systems affected: Apple Macintosh computers running pre-Version 7.
A minor variant of the CDEF virus has been discovered. The damage and
effects are identical to the original CDEF virus. CDEF viruses only
affect Macintoshes running a version of the Mac OS prior to Version 7.
Almost all Macintosh anti-virus tools already detect this new strain
of CDEF. The authors of all other major Macintosh anti-virus tools
are planning updates to their tools to recognize this virus variant.
Some of these are listed below. We recommend that you obtain and run a
CURRENT version of AT LEAST ONE of these programs.
Second Virus (variant): T4-C
Damage: altered boot code; altered/damaged applications; damaged system
Spread: unknown
Systems affected: Apple Macintosh computers. All types.
The T4 virus was discovered in June of 1992. A previously unseen
variant, being called T4-C, has recently been discovered. Many
machines at the discovering site have been affected by T4-C, and the
potential for wider dissemintion exists.
Like the other T4 strains, this virus attempts to modify system boot
code, and also changes the names of some applications to
"Disinfectant". The virus does not work as (we assume) the author
intended, and files may be left with changed names and possibly other
damage. The system file may also be altered, and the damage may
render some systems unbootable.
The virus also attempts to modify application files on the system
disk. These alterations may damage some applications by overwriting
portions of the programs with the virus code; as a result, some
damaged applications may need to be reinstalled after the virus has
been removed.
Once installed and active, the T4-C virus does not appear to perform
any other overt damage. The virus, when active, may print a message
indicating that the system is infected with the T4 virus.
Some Macintosh anti-virus tools already detect this new strain of T4.
The authors of all other major Macintosh anti-virus tools are planning
updates to their tools to locate and/or eliminate this virus. Some of
these are listed below. We recommend that you obtain and run a CURRENT
version of AT LEAST ONE of these programs.
Some specific information on updated Mac anti-virus products follows:
Tool: Central Point Anti-Virus
Status: Commercial software
Revision to be released: 2.01c
Where to find: Compuserve, America Online, sumex-aim.stanford.edu,
Central Point BBS, (503) 690-6650
When available: immediately
Notes: Users do not need a revision of the AV application. Users
need to obtain the 2/24/93 version of the MacSig file.
Tool: Disinfectant
Status: Free software (courtesy of Northwestern University and
John Norstad)
Revision to be released: 3.0
Where to find: usual archive sites and bulletin boards --
ftp.acns.nwu.edu, sumex-aim.stanford.edu,
rascal.ics.utexas.edu, AppleLink, America Online,
CompuServe, Genie, Calvacom, MacNet, Delphi,
comp.binaries.mac
When available: immediately
Note: release 3.0 is *not* a major new release of Disinfectant.
Be sure to read the release notes for details of the version
number change.
Tool: Gatekeeper
Status: Free software (courtesy of Chris Johnson)
Revision to be released: No new revision needed; 1.2.7 works for both.
Where to find: usual archive sites and bulletin boards --
microlib.cc.utexas.edu, sumex-aim.stanford.edu,
rascal.ics.utexas.edu, comp.binaries.mac
When available: immediately
Tool: Rival
Status: Commercial software
Revision to be released: All current versions starting with 1.1.9w are
effective; no new release is needed.
Where to find it: AppleLink, America Online, Internet, Compuserve.
When available: Immediately.
Tool: SAM (Virus Clinic and Intercept)
Status: Commercial software
Revision to be released: 3.5.3
Where to find: CompuServe, America Online, Applelink, Symantec's
Customer Service @ 800-441-7234
When available: immediately
Notes: SAM 3.5 and SAM Intercept 3.0 both recognize these viruses, and
both can remove the CDEF strain. An update is required to
remove the T4-C strain from undamaged files. This may be
obtained from the locations listed above, or by ftp from
rascal.ics.utexas.edu in the mac/virus-catchers/SAM directory.
Tool: Virex
Status: Commercial software
Revision to be released: Current version is effective: 3.91
Where to find: Microcom, Inc (919) 490-1277
When available: February 28
Comments: Virex 3.91 will detect the viruses in any file, and
repair any file that has not been permanently damaged. Users
of Virex, version 3.82 or greater, are already able to detect
the T4-C infection. The CDEF virus is detected and repaired
in versions 3.0 and greater. All Virex subscribers will
automatically be sent an update on diskette. All other
registered users will receive a notice by mail. Datawatch's
BBS number is: (919) 419-1602.
Tool: VirusDetective
Status: Shareware
Revision to be released: no new release is needed; current version is 5.0.6
When available: immediately
If you discover what you believe to be a virus on your Macintosh
system, please report it to the vendor/author of your anti-virus
software package for analysis. Such reports make early, informed
warnings like this one possible for the rest of the Mac community. If
you are otherwise unsure of who to contact, you may send e-mail to
[email protected].edu as an initial point of contact.
Also, be aware that writing and releasing computer viruses is more
than a rude and damaging act of vandalism -- it is also a violation of
many state and Federal laws in the US, and illegal in several other
countries. If you have information concerning the author of this or
any other computer virus, please contact any of the anti-virus
providers listed above. Several Mac virus authors have been
apprehended thanks to the efforts of the Mac user community, and some
have received criminal convictions for their actions. This is yet one
more way to help protect your computers.
------------------------------
Date: Wed, 24 Feb 93 17:12:24 -0500
From: [email protected] (Mark Anbinder)
Subject: Re: Sale of Viri [sic]
Tom Zmudzinski <[email protected]> says...
>> I am just wondering if you got a virus, and passed it on accidently,
>> could you be held civilly at fault for thousands of dollars of
>> damage say if it got into a business?
>
> First, let me say that I am NOT a lawyer (my parents are married), but
> the answer is an otherwise unqualified (and rather loud) *Y*E*S* !!!
Sadly, I have to agree. I, also, am not a lawyer, but I'm aware of at
least one case in which a company's employee was held responsible for
unintentionally introducing a computer virus to his company's
microcomputers. He was fired for a breach of security, and alleged
evidence tracing the virus infection to his system was used.
In this situation he was not made financially or legally responsible
in any sense other than being dismissed. Without details regarding
the company's policies on computer usage, it's hard to say whether his
firing was justified solely on the basis of the virus, or also on
violation of company rules limiting his use of diskettes brought from
outside the company.
I hope that, if a case SHOULD come up with civil or legal action
against someone who is alleged to have introduced a virus
unintentionally, the courts will realize the extent to which that user
is an unwitting agent. Then the burden of proving intent or lack
thereof would fall on the prosecution or plaintiff.
An interesting thought... could this be tied to cases in which someone
has passed on a communicable disease, knowingly or otherwise?
- -------------------------------------------------------------------------
Mark H. Anbinder | Technical Support Coordinator
BAKA Computers Inc. | [email protected]
200 Pleasant Grove Road | (or) [email protected]
Ithaca, New York 14850 USA | Phone 607-257-2070 Fax 257-2657
- -------------------------------------------------------------------------
MUGWUMP.. Ithaca's Macintosh User Group. E-mail me for details, or send
a note to MUGWUMP, P. O. Box 4735, Ithaca, NY 14852-4735, and we'll be
happy to send you a sample copy of CLiCKS, our monthly newsletter.
- -------------------------------------------------------------------------
------------------------------
Date: Tue, 23 Feb 93 19:00:00 -0500
From: Luis Gamero <[email protected]>
Subject: your opinions on virus legality
No. If you keep it in your OWN posession how could it be illegal?
You can own a gun and not use it. That's not illegal.
- --
Canada Remote Systems - Toronto, Ontario
416-629-7000/629-7044
------------------------------
Date: Wed, 24 Feb 93 17:45:47 -0500
From: "Paul D. Bradshaw" <[email protected]>
Subject: polymorphic compiler
Am I missing something important about this polymorphic compiler? If
the good guys have GOOD polymorphic compilers then won't the bad guys
have quality polymorphic compilers as well? Wouldn't this mean that a
virus writer could write one simple virus, and compile it n times to
release n copies into the wild? It seems to me that virus writers
would benefit more from a polymorphic compiler than anti-virus
software writers would. Afterall not that many viruses target
specific anti-virus software.
What if this compiler were applied to the code for an existing
successful virus like stoned?
- -------------------------------------------------------------------------
Paul D. Bradshaw Computing and Communications Services
[email protected] University of Guelph,
[email protected] Guelph, Ontario, Canada
- -------------------------------------------------------------------------
------------------------------
Date: 25 Feb 93 13:44:43 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: general entertainment
[email protected] (Ian Leitch) writes:
> There has been no 'deliberate distortion' of any facts within
> the book, except as declared in the Acknowledgements.
So they are just mistakes made out of incompetentness, then...
> A matter of speculation (such as the identity of 'Diana P') can
> hardly be considered 'a factual error'. It may be wrong, but we
Oh, I agree with that - that the identity of 'Diana P.' as proposed in
the book is pure speculation and has nothing factual in it. I'll just
add that this speculation comes from Mr. Clough - it seems unlikely to
me that somebody in Bulgaria could tell him such a nonsense... For
several reasons... First, as I said, the members of the English high
society are not that popular in Bulgaria at all - for instance, I
wouldn't be surprised if not all people there know even the name of
the Queen. Second, if Darkie meant Princess Diana, he would have
written "Princess Diana". Third, it is a common practice in Bulgaria
to abbreviate somebody's family name to one letter, if you don't want
to reveal his/her identity. Thus, the "P." in "Diana P." is much more
likely to mean an abbreviated family name, than a title.
> have yet to learn who 'Diana P' is. And, even then, who knows?
> One guess is as good as another.
Well, having in mind that the virus is written by a Bulgarian, the
guesses of another Bulgarian about the meanings of the text there are
more likely to be true...
> Some of the 'facts' may be disputed but contributors' memories
> tend to be selective and self-serving, and it is always difficult
> to ascertain 'the truth'.
So, does Mr. Clough imply that he knows 'the truth' better than the
main participants of the stories described by him?
> It would be interesting for Vesselin to identify the
> distortions, so that these can be compared with the research
> material and recorded interviews.
All of them?? OK, by just browsing the chapter about the Bulgarian
Threat from the book, I spotted about 50 different mistakes. Some of
them are minor ones, but this gives you the idea about how exact the
book is. I'll send to the moderator a list of them, but I don't think
that it will be appropriate to post that - it's more than 20 Kb! And
those are the mistakes only in a single chapter! Several of them are
technical mistakes - mistakes that anybody who has analysed the
particular viruses could confirm.
I'll repeat it again - the book is very well written, it is very
readable and entertaining. It's written in that journalistic style,
which is characteristic for some newspapers. I guess that Mr. Mungo
has helped a lot here. The analysis of the situation, and in general
the non-technical and non-factual things are quite deep and correct.
However, the technical part of the book has many incorrectnesses -
incorrectnesses which are forgivable for a technically incompetent
journalist, but not for a security consultant like Mr. Clough.
In short - read the book, it is entertaining and you'll have a very
good time. Just don't rely on it about technical or factual matters.
> Perhaps, he could also identify 'Diana P'?
If I could identify her exactly, this would help me to find out who
exactly the Dark Avenger is...
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 25 Feb 93 14:14:37 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: How to measure polymorphism
[email protected] (Paul Houle) writes:
> I think that the polymorphic compiler approach is still
> stronger than that of the existing polymorphic engines. It also has
I meant that there is no need to use such a strong thing. Using a
polymorphic package (not necessarily one of the existing ones) will be
enough - the installation program will just use the package to encrypt
the executables during installation and to prepend a random decryptor
to them.
> the advantage that it will work fine in operating systems and
> environents that don't like self-modifying code. The compiler could
Even the currently available polymorphic packages have no problems
with self-modification. The MtE- and TPE-based viruses do not modify
themselves once generated - the gust generate modified copies of
themselves on each infection.
> Definitely, the most advanced cryptography technology
> availible should be used.
I'm not sure what you mean, but in most cases cryptographic strongness
is not necessary. A CRC is, for all practical reasons, just as good as
a cryptographically strong hash function, if (but only if!) the virus
has no way to guess the generator.
> The problem is that the keys have to be
> laying around somewhere, even if you are using a public key system --
You shouldn't mess virus protection with crypto protection. The keys
could pretty well lay around - e.g., on a post-it note attached on
your terminal, as soon as the virus has no way to get them from
there... :-)
> Deleting a checksum database would probably be a bad idea for a virus
> - -- and having your integrity checker choke would certainly be a
> warning sign. It would make more sense for a virus to alter the CRCs
> if it were possible for it to read the altered coefficients, keys, or
> whatever it needs to make validation data.
What you are saying above is definitively true and based on common
sense. Yet, I know at least one commercially available anti-virus
package, which provides a checksummer as part of itself. If you just
delete the checksums, generated during the installation, and then
modify (e.g., infect) some of the files, on the next execution of the
package the checksums will be re-generated - on the modified files.
:-( And there are already 2-3 viruses which are using exactly this
trick to circumvent the package - and successfully, on the top of
that... While I have yet to see a virus that tries to forge the CRCs -
not that it's not possible when you know the generator - simply nobody
has done it yet.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: Thu, 25 Feb 93 01:40:56 -0500
From: "Roger Riordan" <[email protected]>
Subject: Detecting Michelangelo (PC)
[email protected] (Greg Broiles) writes
>Greetings - given we are again approaching March 6, I thought it might
>be useful to put together some instructions that would allow DOS-savvy
>users (yeah, both of them :) to look for Michelangelo without needing
>to spend time/dollars tracking down scanning software.
>
>(And yes, I agree that it's important for folks to take further data
>protection measures - but it seems like some protection is better than
>none, especially given the wide distribution of Michelangelo.)
Please! Michelangelo is only one of 30 or 40 viruses which are
moderately common (not to mention the other couplr of thousand in
our zoos) and it is not even particularly bad; it only clobbers your
hard disk on one day of the year, whereas it can fail
catastrophically at any time on any day of the year.
If a user hasn't got any AV software(s)he could have any of these
viruses, and most of them could cause her/him serious problems under
some circumstances. Virtually any AV software is better than
fiddling around with homespun formulae to look for individual
viruses, and at least one excellent product (F-Prot) is free to
private users, and is (I think) readily available on bulletin boards.
So if you know anyone who hasn't any AV software tell them to do
themselves a favour and get a get a reputable scanner, instead of
helping them delude themselves with witchcraft!
Roger Riordan Author of the VET Anti-Viral
Software.
[email protected]
CYBEC Pty Ltd. Tel: +613 521 0655
PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727
------------------------------
Date: Thu, 25 Feb 93 01:41:17 -0500
From: "Roger Riordan" <[email protected]>
Subject: Rebuilding partition tables (PC)
[email protected] (A. Padgett Peterson) writes
>>Has anyone written a program that will allow you to create a new
>>partition table sector from scratch, ...
>Well I have all of the pieces, just not ready for Prime Time but others are
>welcome. Basically all of the information is there (I include a write-up
>in the FixMBR.DOC that comes with the FixUTIL3.ZIP - incidently half of
>those are FREEWARE and the rest are on free trial until 7th March again
>this year).
>
>First you have the BIOS information retrievable with Int 13 Fn 08. This will
>tell you what the CMOS thinks the whole disk is (tracks, heads sectors).
>
>Next you have the Partition Table - this lists the logical drive information
>for each partiton (starting sector, number of sectors, partition type).
>
>Then you have the Dos Boot Record which gives the same information as the
>partition table for each partition.
>
>If there are multiple partitions, each will have its own DBR (and a recovery
>program could just "walk the disk" looking for them) since DOS 3.0 they
>*must* be in the same place.
>Thus the information can be found in not one but *four* different places
>on a DOS disk (Unix or Novell are different but the info is still there -
>just keep fresh batteries in your TI Programmer 8*).
You may recall that AntiCad (which goes off either if you access
ACAD.EXE, or if you hit C-A-D while the tune is playing) overwrites
all tracks on cylinder zero on drives A-D, then further tracks at
increasing intervals till it gets to the end of the disk, then fills
the CMOS RAM with 'FF's. This may not apply to all versions, but
the ones we have seen certainly did, and when they had finished I
think all the above sources had gone.
I imagine this was the type of situation [email protected] (Charles
Howes) had in mind in his original query. Anyone got any other
ideas?
Roger Riordan Author of the VET Anti-Viral Software.
[email protected]
CYBEC Pty Ltd. Tel: +613 521 0655
PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727
------------------------------
Date: 25 Feb 93 08:11:19 +0000
From: [email protected] (Fridrik Skulason)
Subject: Re: EXE/COM switch (PC)
[email protected] (Donald G Peters) writes:
>Here is an idea I have cooked up to defend against some types
>of viruses. It has not (to my knowledge) been in print before.
No wonder, as it is of no use...
>Now any virus which is tailored to work specifically on
>one type of program is not very likely to work...
Wrong. Some viruses use the file name, and they will infect the file
incorrectly, causing infected files to crash.
Other viruses simply check for "MZ" or "ZM", and use that, and would therefore
not be affected at all.
- -frisk
- --
Fridrik Skulason Frisk Software International phone: +354-1-694749
Author of F-PROT E-mail: [email protected] fax: +354-1-28801
------------------------------
Date: Thu, 25 Feb 93 08:27:40 +0000
From: [email protected] (ivind Enger)
Subject: Effect of Form (PC)
We have just discovered that we have been infected by a strain of
FORM. We do, however, suffer from lack of informaion about the effects
of the virus. The virus infects the boot sector and I just read that
it activates on certain days of the month, but what is the actual
action of the virus when it activates?
This brings me to my next qestion: I it possible to obtain a file
somewhere giving a brief description of the action of various vira. I
know that there are lists like virlist.txt that follows the SCAN
program, but I would like a somewhat more extensive description.
Another last qestion: Is there any informaiton around about the virus
TP4 (TP44)?
good health to you all
ivind
------------------------------
Date: 25 Feb 93 14:30:44 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Michelangelo detect/removal instructions (PC)
[email protected] (Greg Broiles) writes:
> Greetings - given we are again approaching March 6, I thought it might
> be useful to put together some instructions that would allow DOS-savvy
> users (yeah, both of them :) to look for Michelangelo without needing
> to spend time/dollars tracking down scanning software.
An alternative would be to get one of those free (or free for
individual use) scanners or Michelangelo-only detectors, if you are
concerned only about this particular virus. There are still a few of
them on our ftp site...
> Seems like the first check should be the amount of system memory
> reported by MEM or CHKDSK - which should be 655,360 on a 640K machine.
> If a machine has 640K, and MEM/CHKDSK reports system memory of 655,360
> - - the machine *as running* cannot be infected, since one of the first
> things Mich does is to subtract 2K from the total system memory
> reported.
The only problem with the above is that it can tell you only if the
machine is NOT infected. Unfortunately, on many installations the
above procedure generates too many false positives to keep the help
desk happy... See the FAQ for more information on this subject.
> DEBUG
> l 0 0 0 1
> [to check a floppy in A: - should be 'l 0 2 0 1' to check C:]
Nope, won't work on a hard disk. DEBUG's "l" command can only read
logical sectors. That's OK on a floppy, but on the hard disk the virus
is in the MBR, which does not belong to any logical partition and thus
can be accessed only as physical sector. So, in this case you'll have
to write a short assembly-language program that reads the MBR.
> Users who find Mich can overwrite it on floppies with the SYS command;
> users who find it on hard disks can overwrite it with FDISK /MBR, if their
> FDISK supports it.
If you are writing this for general distribution, you should specify
the version of DOS that supports this - MS-DOS 5.0.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 25 Feb 93 15:22:42 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: PC Magazine reviews virus scanners (PC)
[email protected] (Christopher Yoong-Meng Wong) writes:
> Have others seen the March 16, 1993 issue of PC Magazine yet? Normally, I
> wouldn't expect this group to care much, but this magazine has tremendous
> influence in the industry. A summary:
> 1. Editors' choices are CPAV and NAV.
This alone tells enough about the level of competence of the
reviewers... I guess they have looked again to the user interface,
instead of to the anti-virus features...
> 2. The great grandaddy of virus scanners, Mc Afee's Viruscan family,
> was not reviewed. Nor was F-prot (though the commercial version was
> reviewed), except as an aside: "... for those comfortable with
> command line operation ... original F-prot".
Maybe they have decided to review only commercial (i.e.,
non-shareware) products?
> 3. Scanning tests involved 11 -- count them -- 11 viruses.
And, if I have heard correctly, none of the more recent widespread
viruses like Form, V-Sign, Joshi are included. That is, a two-year old
scanner would have passed the review rather well... Poor users who
have to rely on the results of such scanners and such reviews...
> Somehow, this review seems out of sync with almost everything I've read
> here about virus scanners. Opinions? It seems to me a letter to the
> letters page signed by a major virus researcher (or ten :-) ) would carry
> a lot of weight.
Good idea. Unfortunately, I am not receiving this magazine, so I have
not read the review and therefore cannot write such a letter. Also, a
letter by the authors of the programs that didn't score well in the
review might also not be the best thing to do... :-)
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 25 Feb 93 15:40:09 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Scanning memory (PC)
[email protected] (ac999512) writes:
> I agree that scanners shouldn't scream and yell when they detect a
> virus floating in RAM that isn't active. Yet on the other hand,
> nothing should be taken for granted as to where a virus is, as stated
> above.
I disagree. Each known virus installs itself at a particular place in
RAM and scanners do just that - scanning for known viruses. There is
no way Stoned can install itself in the DOS buffers, instead of at the
top of the available memory at boot time. I am not saying that it is
not possible to write a boot sector infector which will install itself
elsewhere, but it will not be a Stoned variant any more.
Usually, it is possible to limit the area of memory where each
particular virus can reside. The only slightly difficult case is
viruses like Number of the Beast and LeapFrog, which install
themselves exactly in the DOS buffers. So, it would be difficult to
tell whether you have just copied an infected file (and parts of it
are still remaining inactive in the buffers) or you really have an
active virus. Difficult, but not impossible. All such viruses exclude
the buffer they are using from the chain of available buffers. So, all
you have to do is to verify that the memory scan string is not found
in one of the available buffers...
> I think it best that scanners should check interrupt vectors and so
> forth to determine if the virus is active, then inform the user as to
> the presence of the virus, and whether or not it is active.
That's rather difficult to implement reliably. What does "check the
interrupt vectors" mean? Just look in the Interrupt Vector Table? Many
viruses don't modify it at all. And what if something (a TSR) has
intercepted the vector -after- the virus? What then? Trace the
interrupt vectors? Again - too unreliable on some machines. No, this
is not a good idea...
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 25 Feb 93 16:49:54 +0000
From: [email protected] (JAMES M. O'BRIEN JR)
Subject: Help - GenB and GenP virus problem (PC) (long)
I maintain a LAN that has about 35 pc, a netware fileserver and various
other unix workstations. Recently, (the past few days) we've seen
a number of floopy disks that have been infected with a GenB (Generic Boot)
virus, according to vhield 99 & vshield 100. Now, I've been trying to
ascertain the source of this virus and it is proving difficult to
pinpoint.
We currently have a person scanning all students floppies when they enter
our microlab. All pc's have vshield 100 loaded, scan on access, and
halt on discovery of a virus.
Here's where it starts to get interesting:
Yesterday, it seemed like the virus was appearing out of nowhere. A
student would get their floopy scanned, clean (according to scan 100)
and then proceed to work on a pc. Shortly there after, their machine
would hang, reboot and try to continue working. Access the floppy
and boom, floppy is infected with a GenB virus. Well the floppy is
trashed, and scanning the local HD proves not to be a help as it
comes back clean (scan100). So. where is the darn virus coming from?
I decided to be safe, and reformatted all 16 machines in the microlab
(drastic, but I've got a install disk that helps speed it up..). All
seems well, scanned the file server partitions, all come back clean.
Continue scanning floppies as they enter the lab, catch a few, take
care of them, etc.. Now a floppy that scanned clean is being used
with turbo pascal 6.0, the machine hangs. reboot, back into turbo
pascal, access the floppy, boom it hangs, GenB on floppy. What????
Scan local HD, now there's a GenP on the local HD! What is
going on here?
Anyone have any ideas how to kill this? Anyone aware of incompatiblities
of turbo pascal and vshield? It seemed that a lot of the problems
where with low density disk formatted as high density (darn ps/2's)
but it hasn't always been the case.
Thanks
Jim O'Brien University of Maryland Eastern Shore
[email protected] Network Manager
------------------------------
Date: Thu, 25 Feb 93 19:23:42 +0000
From: 007 <[email protected]>
Subject: Re: Question about Patricia Hoffman and John McAfee
[email protected] (McAfee Associates) writes:
>[email protected] (007) writes:
>>[email protected] (McAfee Associates) writes:
>>>There is no close link between McAfee Associates and Ms. Hoffman, at
>>>least, none different from that between her and any other anti-viral
>>>vendor.
>>Really? I wonder why Ms. Hoffman states in her "A word from Patricia..."
>>section:
>>
>> A special thanks goes to John McAfee for the countless hours he
>> has spent reviewing VSUM prior to its release.
>>
>>Seems she has a bit more of a connection with SCAN than "any other
>>anti-viral vendor."
>
>Simply because John McAfee would spend hours on the phone telling her
>about what viruses were new, where they came from, how common they
>were, etc. If you think you have any such information that may be of
>use to Ms. Hoffman, I'd suggest that you contact her. Perhaps you too
>can get your name mentioned in her virus summary.
That's very nice of Mr. McAfee. It also explains much about the
information found in VSUM. As to contacting Ms. Hoffman, I did
exactly that about a year and a half ago. After disassembling the
Cinderella virus, I sent a copy of my findings to Ms. Hoffman so she
might be able to update her entry for Cinderella. I never received
any reply, and the entry on Cinderella remains the same as it always
was.
VSUM is a potentially very useful product. How many times on this
list alone have we seen people asking "I've got XXXX virus, what does
it do??" My only beef with VSUM is that the information is SO
inaccurate. The VSUM hypertext interface is extremely easy to use, if
only we could couple that with some genuinely accurate information!
Currently, MSDOSVIR is the only list I know of that contains accurate
or nearly accurate virus info. Frisk also has good information, but
it is rather brief.
What I'd like to see in a virus information listing:
+ Accurate virus info, and how to contact the person who disassembled the
virus. I'm sure Ms. Hoffman has not looked at a disassembly of every
virus in her listing. I suspect that frisk has. Reports of errors
in the listings should at least be acknowledged.
+ Easy to use. Ms. Hoffman comes through with flying colors on this one.
+ CARO names for variants.
+ Cross-indexing names with output from popular scanners. VSUM used to do
this with SCAN, but SCAN seems to change its naming scheme with each new
release, making this difficult or impossible to implement.
Too bad we can't get MSDOSVIR in hypertext format.
-- 007
- --
000 000 7777 | [email protected]
0 0 0 0 7 |-----------------------------------------------------------
0 0 0 0 7 | Childhood is short...
000 000 7 | ...but immaturity is forever.
------------------------------
Date: 24 Feb 93 23:51:00 -0600
From: "Rob Slade, DECrypt Editor, VARUG NLC rep, 604-984-4067" <roberts@decu
s.arc.ab.ca>
Subject: Michelangelo Functions (CVP)
HISVIRX.CVP 930210
Michelangelo Functions
The replication mechanism of Michelangelo is basically identical to
that of Stoned. A boot sector infector, it replaces the original
boot sector on a floppy disk with itself. The original boot sector,
whatever it may be, is placed in a new position on sector 3 or 14 of
the disk, and the virus contains a "loader" which points to this
location. After the virus loads itself into memory, the original
boot sector is run, and thus, to the user, the boot process appears
to proceed normally.
When a computer is booted from an infected disk, the virus first
checks to see if a hard disk is present. If it is, the virus
infects the hard disk in much the same way as a floppy, except that
the master boot record, or partition boot record (the first sector
"physically" present on the hard disk) is replaced (in sector 7)
instead of the boot sector. In a sense, this method of replication
is simpler than that of other boot sector infectors. It is always
the "physical first" sector that is affected. This also takes place
at a very low level, not requiring MS-DOS to be fully loaded to
operate.
As with Stoned, there is no "stealth" involved. Examination of the
boot blocks with a sector editing utility will clearly show the
difference between a "valid" sector, and one which is infected.
(Stoned is easier to spot, with the text message within the sector,
but the absence of the normal system messages should be a tip-off.)
In addition, Michelangelo reserves itself 2K at the "top of memory":
a simple run of the CHKDSK utility will show "total memory" on the
system, and if a 640K machine shows 655,360 bytes then you do *not*
have Michelangelo. (There may be other reasons than a virus if the
number is less.) Removal is a simple matter of placing the original
sector back where it belongs, wiping out the infection. This can be
done with sector editing utilities, or even with DEBUG. (There are
cases where a computer has been infected with both Stoned and
Michelangelo. In this situation, the boot sector cannot be
recovered, since both Stoned and Michelangelo use the same "landing
zone" for the original sector, and the infection by the second virus
overwrites the original boot sector with the contents of the first
virus.)
When an infected computer boots up, Michelangelo checks the date via
interrupt 1Ah. If the date is March 6, the virus then overwrites
the first several cylinders of the disk with the contents of memory
(generally speaking, not much). There are two limitations of this
damage. Interrupt 1Ah is not available on the earliest PCs and XTs.
This is not to say that only ATs and up are vulnerable: "turbo" XTs
have this interrupt as well. However, the disk that is overwritten
is the disk booted from: a hard disk can be saved by the simple
expedient of booting from a floppy. Also, the damage is only
triggered at boot time.
copyright Robert M. Slade, 1992 HISVIRX.CVP 930210
============== ______________________
Vancouver [email protected] | | /\ | | swiped
Institute for [email protected] | | __ | | __ | | from
Research into rslade@cue.bc.ca | | \ \ / / | | Mike
User p1@CyberStore.ca | | /________\ | | Church
Security Canada V7K 2G6 |____|_____][_____|____| @sfu.ca
------------------------------
Date: Thu, 25 Feb 93 05:49:44 -0500
From: [email protected]
Subject: Re: Virus Survey Results
> Date: 20 Feb 93 03:35:43 +0000
> From: [email protected] (Jay Elvove)
> Subject: Virus Survey Results
> In November, I distributed a questionnaire [re] ... computer viruses ... I
have UUENCODED the results ... anonymous FTP from info.umd.edu in the file
/info/Computers/PC/Unix/uuexe520.zip.
- - ---cut here------cut here------cut here------cut here------cut here---
begin 644 vresults.txt
M("LM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM ... etc etc
For those who can't FTP from USA, and who can't translate uucode, here is a
plain language adaptation of this message with lines <= 78 chars long:-
[VIRUS SURVEY RESULTS]
How many PCs do you use or oversee?: 2-4 = 1, 10-19 = 1, 20-49 = 11, 50+ =
39, total = 52.
PC environment: solitary = 0, open lab = 5, restricted lab = 1, departmental
LAN = 17, combination of these = 30, total = 53.
% of users are: faculty = 13.5%, staff = 29.1%, graduate = 6.6%, undergrad =
17.3%, other = 1.3%, non-academic = 22.7%, n/a = 9.4%, total = 100.0%.
Perceived threat fom viruses: extreme = 2, very = 6, moderate = 31, little =
13, none = 1, total = 53.
How many virus incidents in last 6 months: 1 = 3, 2-4 = 18, 5-9 = 5, 10-19 =
7, 20-49 = 5, 50+ = 1, 0 = 14, total = 53.
What viruses: Stoned = 31, Jerusalem = 8, Michelangelo = 12, Yankee Doodle =
3, Form = 3, other = 24, = 1, total = 82.
Damage: files = 8, diskettes = 4, FAT = 4, down = 5, little = 9, other = 3,
none = 9, n/a = 15, total = 57.
Time to remove virus or recover from effects: < = 5 mins = 8, 6-15 mins = 6,
16-30 mins = 3, 31-60 mins = 3, 1-4 hrs = 5, >4 hrs = 7, n/a = 21, total = 53.
Greatest source: faculty = 5, staff = 9, graduate = 8, undergrad = 14, other
= 8, don't know = 4, n/a = 14, total = 62.
Likeliest source: faculty = 4, staff = 9, graduate = 3, undergrad = 19,
other = 15, don't know = 1, n/a = 2, total = 53.
Likeliest transmission medium for viruses: floppy = 44, net/FTP = 4, BBS =
4, other = 6, n/a = 2, total = 60.
Scanning frequency: every boot = 17, daily = 4, weekly n = 11, monthly = 7,
rarely = 12, never = 1, n/a = 1, total = 53.
How many of your PCs use TSRs to detect viruses?: 2-4 = 13, 5-9 = 1, 10-19 =
2, 20-49 = 6, 50+ = 15, 0 = 15, n/a = 1, total = 53.
Backup frequency: daily = 23, bi-weekly = 1, weekly = 12, weekly = 7, weekly
= 8, weekly = 1, = 1, total = 53.
Prevention: TSRs = 19, scanning = 35, user education = 14, official policies
= 12, backups = 10, other = 6, nothing = 1, n/a = 3, total = 100.
Antivirals in use: F-Prot = 21, Vshield = 5, Scan = 5, NAV = 3, other McAfee
= 5, other = 10, none = 20, total = 69.
Affiliation: faculty = 6, staff = 30, graduate = 1, undergrad = 2, other =
1, non-academic = 12, = 1, total = 53.
Source of info: UMCP = 15, Novell = 26, VIRUS-L = 10, E-mail = 2, total =
53.
Site type: EDU = 41, COM = 12, total = 53.
------------------------------
End of VIRUS-L Digest [Volume 6 Issue 35]
*****************************************
|
|
