|
Virus_l Digest Vol 6 Issue #022
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.
Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
id AA04557; Tue, 9 Feb 1993 17:58:32 +0100
Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA15334
(5.67a/IDA-1.5 for <[email protected]>); Tue, 9 Feb 1993 10:50:12 -0500
Date: Tue, 9 Feb 1993 10:50:12 -0500
Message-Id: <[email protected]>
Comment: Virus Discussion List
Originator: [email protected]
Errors-To: [email protected]
Reply-To: <[email protected]>
Sender: [email protected]
Version: 5.5 -- Copyright © 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <[email protected]>
To: Multiple recipients of list <[email protected]>
Subject: VIRUS-L Digest V6 #22
Status: RO
VIRUS-L Digest Tuesday, 9 Feb 1993 Volume 6 : Issue 22
Today's Topics:
Re: Mainframe viruses? [Sam Wilson:06/13]
Re: Infection question
Re: Patriotic Virus Writers?
Re: scanners.
re: new NIST Pub (CORRECTION)
Undecidability (was: On the definition of viruses)
Re: How to measure polymorphism
Re: os2-stuff (OS/2)
Re: Vshield vs Virstop (PC)
Norton buggy??? (or I have a PROBLEM!) (PC)
Re: PKZIP 2'S AV is cracked (PC)
Re: can anybody help my little lost computer? (PC)
New Virus (PC)
Mr. BIOS (PC)
ANSI Bombs (PC)
696 Virus? (PC)
New virus in Germany :-( (PC)
DAME/MtE (PC)
re: Virus scan on a compressed drive (PC)
dame virus (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. (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu 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
----------------------------------------------------------------------
Date: Fri, 05 Feb 93 19:48:32 -0500
From: Anthony Naggs <[email protected]>
Subject: Re: Mainframe viruses? [Sam Wilson:06/13]
Sam Wilson, <[email protected]>, recently posted a copy of an
article from the UK trade paper "Computing", entitled:
> Mainframes hit by epidemic of viruses
> =====================================
As Klaus Brunnstein, <[email protected]>, noted:
> Sam Wilson mentioned a "survey of 816 European and North America mainframe
> sites (with) ...35.5% .. disasters .. 60% of which had been due to viruses".
It seems that a journalist misunderstood the survey results, or at least
misrepresented them. The following letter appeared in this week's edition
of Computing, and seems to make more sense:
[reproduced in full, but without permission]
- - - - -
Mainframes are in good health
=============================
I read with sheer horror your article 'Mainframes hit by epidemic of viruses'
(Computing, 21 January).
Those who do not know better may reasonably infer that the numbers reported
refer to occurrences of viruses on actual mainframes, but, although the
survey in question is sent to sites with mainframes, the question asked if
the installation [site] had suffered viruses. It is therefore invalid to
conclude that the viruses actually occurred on the mainframe.
Furthermore, the bar chart you showed in the article seems to show a rise in
viruses from 1991 to 1992, but investigation into the Ibex results shows
that this chart actually shows the five year totals, so the 1992 five year
total includes the 1991 total. The annual increment was actually less than
half of the increase in five year totals.
Last year, in one part of Africa, the stork population decreased sharply.
Also in the same area the human birthrate happened to fall. What would
your reporter have concluded from this?
Richard Phillips, Reed Travel Group, Dunstable, Bedfordshire
- - - - -
Hope this helps,
Anthony Naggs
Software/Electronics Engineer P O Box 1080, Peacehaven
(and virus researcher) East Sussex BN10 8PZ
Phone: +44 273 589701 Great Britain
Email: (c/o Univ of Brighton) [email protected] or [email protected]
------------------------------
Date: 07 Feb 93 19:56:24 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Infection question
[email protected].edu writes:
> But in my (humble?) opinion, a boot sector infector does attach itself to
> a program, i.e. the bootstrap loader. This program just doesn't happen to
> be contained in a file.
It depends on how do you define "attach". A boot sector infector does
not modify or attach itself to a bootstrap loader - it just moves this
loader to a different place and puts its own body at the original
place. Furthermore, viruses like Stoned will infect and spread even if
the bootstrap loader is absent - e.g. a diskette with a zeroed out
boot sector is both infectable and infective after infection. So,
you'll have to define "attach" in such a way that defines "attaching
to the execution process of a program" or something like that.
> I'm not quite as certain what to say about companion viruses. I don't
They are not the only problem. The Dir_II virus modifies the directory
entries - not the files themselves. The StarShip virus infects the MBR
by modifying only three bytes of the partition table -data-... And so
on...
> Still, without the "host" program the companion virus would never be
> executed by the user, would it?
It depends. Consider an EXE file, "infected" by a companion virus. If
you delete the host (i.e. the EXE file), the virus will still be able
to spread, in most cases.
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: 07 Feb 93 20:29:44 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Patriotic Virus Writers?
[email protected] (Sam Wilson) writes:
> The following letter and editorial response appears in the February
> 1993 issue of the UK magazine 'Personal Computer World' under the
> heading "Spreading viruses":
[ARCV's silly letter deleted to save the net.bandwidth.]
> ARCV
> (Association of Really Cruel Viruses)
> [And the editor replies:]
> You say you're not depraved people? Perhaps you weren't beaten as
> children, but as far as we're concerned you should be beaten as
> adults.
According to the latest information, six members of the ARCV group
have been arrested. Perhaps this will stop them from writing viruses
any more...
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: 07 Feb 93 20:33:31 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: scanners.
[email protected] (Ed Street) writes:
> I know this is probably a dumn question but I was wondering about the
> realistic aspects of scanners like do they really protect as much as
> some of the people that I have talked to seem to think? In my opinion
> they are just merely an aid to problem solving and should not be used
> as a general "cure-all"
All a scanner can do is to detect known viruses. Nothing more. Good
scanners detect most known viruses, worse scanners detect fewer of
them. No scanner detects -all- known viruses, because new viruses are
created literally every day.
A scanner is useful for:
1) Checking that a system is virus-free before installing some more
sound virus defense, like an integrity checker.
2) Checking new software before you execute it or install it on your
system. This way you can detect a virus before it gets the chance to
execute.
3) Trying to figure out what has happened when your more serious
defense (the integrity checker) has raised an alert and you are
wondering whether it is a known virus.
Because of the above, scanners are -useful- and should be used as a
first line of defense. (Up-to-date scanners, of course; an old scanner
is worse than no scanner at all, because it gives you a false sense of
security...) However, no defense should rely on scanners -alone-,
because they are a -weak- defense. You must use a layered approach,
with several protection levels, like integrity checking software, some
kind of access control, and, of course, backup.
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: Mon, 08 Feb 93 11:26:24 -0500
From: Tim Polk <[email protected]>
Subject: re: new NIST Pub (CORRECTION)
Ouch! I *swear* I proofed that message, but I switched the second
and third parts of the address of the ftp server.
The correct name is:
csrc.ncsl.nist.gov
I have successfully printed this PostScript file on several different
printers. However, I have been notified that this file will not
print on some Adobe-licensed printers. If it fails on your printer,
please let me know. I will be happy to send a hardcopy.
Sorry for any difficulty, and thanks to those who sent me notice of
the switch.
Tim Polk
[email protected]
------------------------------
Date: Mon, 08 Feb 93 11:27:26 -0500
From: Y. Radai <[email protected]>
Subject: Undecidability (was: On the definition of viruses)
(First, note that I've changed the Subject line. I didn't notice
how inappropriate it was until someone wrote me on the basis of my
postings that I seem to have an interest in defining virus items.
Secondly, although I address this reply to Fred Cohen, I think it
will also serve as a reply to most of the comments on this subject
made by Vesselin, Padgett and others.)
In reply to my statement:
>> Suppose a program contains code for replication, but only within a
>> statement of the form "If <condition> then <replicate>", where
>> <condition> is something which depends on the run-time environment,
>> e.g. on the input which a user supplies. Can a detection program
>> discover whether the program actually does replicate?
Fred Cohen replies:
> Only at runtime!
True, provided the question is interpreted as asking whether it
replicates on a *particular* execution. (As my later discussion
indicates, I was also interested in determining whether the program
replicates on *every* execution, or on *at least one* execution.)
> Also, instructions
> is a relative term. I prefer to discuss sequences of symbols. These
> symbols can be interpreted by any number of mechanisms.
Agreed, but since that wasn't subject to controversy, I simplified the
wording by speaking of "instructions".
>> (b) a virus is a sequence of instructions which replicates on *at
>> least one* execution;
>
> Same as above, but add - if *at least once* does it mean that if a copy
> program copied it, it would be a virus? Example: run your program which
> halts, then later, someone copies it once, and bingo, it's a virus. The
> reason for *every* is that we can associate the replication property
> with the virus and not the rest of the machine.
I suspect that we are using the phrase "at least once" in two differ-
ent senses. To clarify this, let's talk about "generations" of a
virus: the virus in the original infected program is of generation 0,
and whenever a virus of generation n infects, it creates a virus of
generation n+1. Now if I understand you correctly, you mean that in
order for something to be a virus, *the number of generations must
be (potentially) infinite*. Otoh, when I used the phrase "at least
once" in definition (b), I was referring to a *conditionally
infecting* virus (which I think is what you call a "partial" virus).
I.e., an infected program (of any given generation n) can be a virus
according to definition (b) even if it infects on only a single
execution (thereby creating a single virus of generation n+1). But I
did not intend to imply that such a virus would also be limited in the
number of generations.
>> If the decision is to be made by appearance of the program alone,
>> then the simplest case is ©, for suppose that the program asks the
>> user to supply two numbers, x and y, and <condition> is "x < y". Then
>> it is completely obvious that fulfillment of this condition cannot be
>> determined without actually running the program, hence whether the
>> program is a virus is undecidable by appearance of the program alone.
>
> The problem is that in the Turing Machine model, there is no `input'!
> All the information needed for the computation is on the tape and in the
> FSM, and is thus provided a-priori. Input is modeled as a preexisting
> tape state. The undecidability proofs I generated relate to ANY inputs
> (i.e. any tape state can exist outside the virus). They are thus `input'
> independent.
This seems to me irrelevant, since I was not using the Turing Machine
model! When I spoke of user input, I was merely trying to give a
*convenient example* of a run-time environment on a computer.
(Actually, I'm not sure we're using "environment" in the same sense.)
>> Note that this argument does not require the assumption that the
>> computer has an infinite amount of storage, as Fred's proof does.
>
> Sure it does - we can identify that under one set of inputs it's a
> virus, and under the other it is not. As we watch the inputs, there
> comes a point in time when we say `VIRUS!!!'.
At the point I made this statement, I was referring to definition ©,
where we're asking whether the given condition ("x < y" in my example)
is satisfied on a *given* input (x,y). Also, I was talking of having
to determine whether the condition is satisfied *merely by appearance
of the program* (as opposed to using its runtime behavior). Therefore,
we cannot "watch the inputs", and I fail to see anything in your reply
which shows the need for an unbounded amount of storage in order to
prove undecidability by appearance alone.
>> Not only can we not decide this
>> by appearance of the program, but even if we run this program a zil-
>> lion times and the program doesn't replicate, that doesn't prove that
>> it can *never* replicate; all one can say is that the program hasn't
>> replicated *so far*.
>
> Not right. For finite sized systems, these problems are not unsolvable.
> They merely take a lot of time to solve. We could literally try all
> possible integers that could fit in the finite sized computer.
It seems that many readers, perhaps including you, are confusing the
two parts of my argument, so let me make this clear. Part 1 assumed
that Definition © was chosen, and concerned detection by *appearance
alone*. It had nothing to do with unsolved problems, and it was
valid even when the amount of storage was finite. Part 2 assumed
that Definition (a) or (b) was selected, and concerned detection by
*run-time behavior*. It spoke of unsolved problems, did not claim to
be conclusive, and there was no claim about the amount of storage.
The section you are quoting above deals with Part 2, and there I
never said that the problems are unsolvable on a finite computer.
> All unsolvable problems of this sort depend on the size of the integers
> being infinite. - As above. There is no undecidability for finite sized
> computers, and there can never be.
Perhaps we mean different things by "undecidable". Maybe you mean
undecidable by *any* means, appearance *or* behavior. I claim that if
one chooses definition ©, and if <condition> is something which is
sometimes satisfied and sometimes not (e.g., if it is "x < y" where x
and y are numbers supplied at runtime by the user), then the question
whether the program is a virus is obviously undecidable *BY APPEARANCE
ALONE*, even on a *finite* machine.
> Also, solving Fermat's last Theorum will neither make you
> famous, nor solve all of the world's unsolved problems. They used to
> say the same thing about the 4-color graph problem, but some people
> proved it with a computer theorum prover. What was their name?
I never said that solving Fermat's Last Theorem *alone* would solve
*all* the world's unsolved problems! My hypothesis for that conclu-
sion was being able to "write a program which could decide whether
the resulting programs [after substitution of *all* the other unsolved
problems as the <condition>] are viruses".
As for making one famous, I'm sure the solvers of the 4-color
problem are reasonably famous among most of the people who are
interested in that problem, even if *we* don't remember their names.
> As I mentioned above, there is no problem that can *NEVER* be solved for
> a finite machine. Unsolvable problems only occur in infinite state
> machines.
As I mentioned above, the "x < y" case with definition © is undecid-
able by *appearance alone*, even on a finite machine.
> The reason undecidable problems are undecidable is that they CAN
> NEVER be solved by ANY Turing Machine. It does not depend on the state
> of mathematics of the day or a proof not yet found or the number of
> computations we can perform per unit time. In that sense, it is an
> absolute limit of the nature of the machine. All of the realized
> digital computers to date and all of the theorized finite discrete
> valued computers fall into a subset of Turing Machines, and thus no
> undecidable problem can be solved by any of them either. That's why
> the concept is so powerful.
> Instead of running to `unsolved' problems, it seems a much better
> choice to run to `unsolvable' problems in your proofs. That's why I
> used the halting problem to show that virus detection is undecidable
> rather than Fermat's last theorum. I didn't want to show computational
> complexity, but unsolvability. ....
I agree with this, but perhaps you don't understand my motivation (and
the same goes for many others who commented on my posting). In Part
2, I was not attempting to give a rigorous proof! (As I wrote, I was
presenting a non-conclusive argument, and I twice used the phrase "for
all practical purposes".) My purpose in presenting the argument was
to explain the situation to someone who does not have the necessary
background, in as *intuitive* a manner as possible. Now from a logi-
cal point of view, proofs such as yours are perfectly valid. More-
over, my idea of "intuitive" may be quite different from yours. How-
ever, my experience shows that there is something about proofs like
yours which many (even intelligent) people find *unconvincing* from a
*psychological* point of view. I have had much better success if I
use my non-rigorous argument rather than your rigorous proof. So
please try to take into account my purposes, which are very different
from yours.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Mon, 08 Feb 93 18:48:44 -0500
From: "David M. Chess" <[email protected]>
Subject: Re: How to measure polymorphism
>From: [email protected] (Michael Favor)
>In his paper, did ... Chaitin explain how to 'find' the 'smallest'
>program in an objective way? It seems easy enough to measure two
>programs and decide which one is smaller or simpler, but how can one
>generate these programs in the first place without using all of the
>subjective intuition of the programmer?
No, and in fact another interesting result he has is that it's
in some sense hard to prove that a particular string is random
(if I remember it right with this cold, a system that has order-n
bits can't prove that a string is more than order-n-bits random;
that's very rough). One reaction to this would be "so much the
worse for this notion of randomness; I'll find one in which you
*can* feasibly prove that things are random". But I think this
notion of randomness has lots of nice properties, including
intuitiveness (after all, if it's easy to write a short
program that produces the string, it's clearly not very random
on an intuitive definition, since you can describe the string
by outlining the algorithm of the program, and an easy-to-
describe string isn't very random). I think it may be just
a fact about what we mean by "random" that (while it can
be defined quite objectively), it's hard to prove that a
thing is random.
I was going to put in a long tangent here, but it's not
really at home on VIRUS-L. For some mental fun, though,
think about what happens if you have a simple test for
randomness, and then you use it to produce descriptions
like "the smallest random number greater than 10-to-the-100th".
Is that number really random? Really? *8)
Anyway, to get back to polymorphism briefly, I think that
"how long is the shortest known algorithm that reliably
recognizes these things?" is a good rough measure of
degree of polymorphia (hehe), even though "how long is
the shortest *possible* algorithm that..." is a very hard
question.
- - -- - / We have a little garden,
David M. Chess / A garden of our own,
High Integrity Computing Lab / And every day we water there
IBM Watson Research / The seeds that we have sown.
------------------------------
Date: 07 Feb 93 20:22:41 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: os2-stuff (OS/2)
[email protected] (Anthony Naggs) writes:
> I don't think so, but OS/2 (2.x) DLLs run in the CPU's 'Protected Mode'
> and so will not be visible to the DOS box. If the virus is OS/2 aware
> then it can interact with OS/2 form the DOS box, but I don't know what
> the scope of that is.
Yeah, but we were talking about scanners and scanners can detect only
known viruses. Since no known virus does what you describe above, this
means that we don't need to scan the DLL files - unless they can
become infected by mistake. So the point of my question was - can they
become infected by mistake by any of the known viruses?
> There are three big reasons not to worry at the moment:
> 1 OS/2 DLL files have a different internal layout from DOS programs,
> preventing DOS viruses from successfully infecting them.
> 2 OS/2 (2.x) programs (including DLLs) run in "Protected Mode" which
> means that code for the "Real" or "Virtual" modes used by DOS is
> unlikely to work.
> 3 Even if these could be overcome a DOS virus would fail as soon as it
> tried an Int 21h call.
None of those reasons would be valid, if any of the known viruses
could infect DLL files BY MISTAKE. OK, they will crash, OK, the virus
won't run, etc., but if they can become infected, you still must scan
them - at least to determine which of them are damaged by the virus.
So, I am asking again - can some of the known viruses infect a DLL
file (even by mistake, even incorrectly)? I think that none of them
will do that, but maybe I am wrong...
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: Fri, 05 Feb 93 18:59:17 -0600
From: [email protected]
Subject: Re: Vshield vs Virstop (PC)
[email protected] (Vesselin Bontchev) writes:
>bill.lambdin%[email protected] (Bill Lambdin) writes:
>
>> Vshield can detect new and unknown viruses except for two types.
>>>
>> 1. Stealth
>> 2. Companion infectors.
>
> 3. Unknown viruses that patch VShield in memory to deactivate it.
> 4. Unknown viruses that patch VShield on the disk to deactivate it.
> 5. Unknown viruses that intercept the alert message VShield tries to
>output and prevent its output.
> 6. Unknown viruses that remove the checksums created by SCAN.
> 7. Unknown viruses that patch the database of checksums after they
>infect the file, so that the new checksum entry corresponds to the
>already infected file.
> 8. Unknown viruses that forge the checksum algorithm used by SCAN
>and infect the files without changing their size/time/checksum
>computed with this algorithm.
> 9. Unknown viruses that modify the CONFIG.SYS/AUTOEXEC.BAT files to
>prevent VShield from being run (and that optionally put a call to a
>fake program that generates a fake message that VShield is loaded and
>running).
> 10. Unknown viruses which infect only floppies.
> 11. Unknown viruses which infect only objects known to be modifiable.
> 12. Unknown slow viruses.
>
>Makes quite a long list of exceptions for a claim "can detect new and
>unknown viruses", doesn't it?... Never underestimate what an unknown
>virus could do...
Isn't this also true for VIRSTOP??????????????????
------------------------------
Date: Sat, 06 Feb 93 02:08:34 +0000
From: [email protected] (Alan Mead)
Subject: Norton buggy??? (or I have a PROBLEM!) (PC)
I think I found a bug in the Norton virus scaner NAV.EXE
(dated 5-28-92). I don't know what version or anything.
Here's what happened:
I wrote a program for my wife's employers. I copied it onto her PC at
work about a month ago.
Today, I get home and my wife has left this message on our machine
about "don't boot my computer" because "we have a virus" and everyone
at her work hates her and the Data Processing people are running around
muttering stuff like "Now I'm going to have to check every computer in
accounting" etc.
Mortified, I download the very latest McAuffe scan (1-21-93) and I scan
my every file on my only drive, C: (SCAN C: /A /SUB). I get nothing.
Susan gets home with the Norton disk. We use the Norton scanner
(NAV.EXE) on my C: and it fails to find anything. BUT, it turns out I
deleted the file that allegedly carries the virus ("a strain of
CVIR").
So I Norton the backup disk and, sure enough, it flags an executable of
a Turbo Pascal program of mine. THEN I McAuffe it and I get NOTHING.
So already I'm suspicious because how can my whole fucking C: be cool
[by BOTH programs] but that one file (that I created) be sick.
So I copy the source onto C: and recompile. The byte length of the
fresh copy and the old, allegedly infected, copy is exactly the same.
And, get this, fucking Norton flags my new, freshly compiled executable
again.
What do you think? I find it unlikely that I have a virus and
(snicker, snicker) I LOVE the fact that these morons are spending their
Friday night disinfecting clean machines. Also, I should think Norton
would want to know about this.
- -alan d mead
------------------------------
Date: Fri, 05 Feb 93 01:10:45 +0000
From: [email protected] (McAfee Associates)
Subject: Re: PKZIP 2'S AV is cracked (PC)
Hello Mikko Hypponen,
You write:
>The following is ment to inform the participants of this newsgroup. I
>am not bashing PKWare nor any other company or individual.
>
>The "Authentic files Verified" feature of PKZIP 2 has been compromised
>and cannot be trusted.
[...description of PKWare's Authenticity Verification feature and its
uses deleted for brevity...]
>The computer undergound has been busy trying to crack the new
>AV-scheme. Now it has obviously been done. A file called
>MAKAV204.ZIP is circulating around the underground BBS's and with
>it anybody can secure an PKZIP 2 archive to any name.
>
>To demonstrate this, I'm enclosing an UUencoded zip-file,
>which will show an AV to "Zip Source: McAFEE ASSOCIATES" when
>unpacked with PKUNZIP 2.04c.
[...I have deleted the UUENCODE'd file...]
>It remains to be seen whether McAfee Assiciotes begins to ship their
>products archived (and secured) by PKZIP 2.04c or not. Their latest
>release, 9.2V100 was archived with PKZIP 1.1.
We will continue to use PKZIP Version 1.10 to compress our files for
the forseeable future because 1.10 is still used more frequently then
2.04C, there is no "exportable" version of PKUNZIP V2.04C available
from PKWare (yet), and lastly, PKZIP Version 2.04C has several bugs
in it that make it undesirable for use in distributing software
(PKWare has released a newer version, 2.04E, but we will wait to
see how stable that is before we consider using it.).
>
>It should also be noted that the AV in above zipfile does not match
^^
I am going to guess that you meant serial number here, not the "-AV"
which appears after each file is unzipped.
>the number shown before the authors name. McAfee's number should be #
>NWN405 (at least that was with pkzip 1.1). In fact this faked zip
>displays the number "# PKW655" which is the AV-number for PKWare
>itself. The cracker probably found a short-cut way by just changing
>the name and not the number.
>
>Please note that the similar "Security Envelope" feature of ARJ 2.30
>has also been broken. The author of ARJ, Robert K. Jung, is currently
>working on a new method the secure the ARJ archives.
Like many other readers of the comp.virus newsgroup (and its digest
counterpart, VIRUS-L), I appreciate it when computer security and
integrity are discussed, especially when they relate to our (McAfee
Associates, that is) programs.
However, I certainly feel that any discussion of such issues much
be discussed in a tactful manner--and a competitor pointing out an
example of a security risk, complete with actual working example,
in another company's product is not necessarily the best way to do
this: You need not present the Internet with a forged .ZIP file
merely to prove that PKWare's Authenticity Verification for Version
2.04C of their program has been cracked.
Reporting that such a risk exists is adequate for the purposes of
this newsgroup; one does not include a copy of a new virus or post
the source code for a new method of infection to show that it exists.
The Authenticity Verification and accompanying serial number generated
by the PKZIP program are used by us for providing our users with a
degree of security, they are by no means final or absolute. However,
it is very unlikely that both the -AV and serial number will match up
in a cracked version of PKZIP.
I believe that it is far better that some means of protection be
provided then none at all. Our programs are directly available
from us via our BBS, forum on CompuServe, and mcafee.com ftp site
on the Internet, in addition to sites such as the SIMTEL20 archives
and garbo.uwasa.fi which I directly send the programs to. If any
one ever has a question about the integrity of a .ZIP file they've
received, then they should delete it and download it from one of
these avenues instead.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
PS: Please (!) direct any follow-up comments to me via e-mail, I have
no desire for this newsgroup to become a battleground. :-)
- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | [email protected]
Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714
95054-3107 USA | USR HST Courier DS | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR
------------------------------
Date: Fri, 05 Feb 93 18:26:04 +0000
From: [email protected] (McAfee Associates)
Subject: Re: can anybody help my little lost computer? (PC)
Hello Dan Greenspan,
You write:
> I run an ibm type machine. Lately my machine began acting up
>and now I have three invisible files in my hard drive instead of two.
[...deleted...]
If you have labeled your hard disk drive with the DOS LABEL command, the
label itself will sometimes be reported as a hidden file, depending upon
which program you use to look for hidden files.
If you are running MS-DOS 5.0, you can get a complete listing of hidden
files by typing "DIR /AH /S" from the root directory of your drive. This
tells the DIR command to search all subdirectories for files with the
hidden attribute.
Regards,
Aryeh Goretsky
- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | [email protected]
Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714
95054-3107 USA | USR HST Courier DS | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR
------------------------------
Date: Sun, 31 Jan 93 20:57:00 +0100
From: [email protected] (Inbar Raz)
Subject: New Virus (PC)
[email protected] (Amir Netiv) writes:
>> It looks like a variant of te WHALE, but larger, and
>> harder to remove
> Whell, it could be as you say (a variant of the WHALE), but it would
> be rather surprising, since the Whale is an old one and from a viral
> point of view... an unsuccessful one.
Don't be so sure.
A lot of 'virus writer wannabe's simply attain virus sources, make
some modifications to them (either to avoid detection, to try new
techniques or just to save the skeleton writing) and compile them.
For someone who's not very smart, the Whale virus would sound like a
good work- grounds, because it is fairly known that most of the virus
code is dedicated to anti-debugging (which consequently made it very
slowing), and that would aledgedly make it harded to detect.
Inbar Raz
- - --
Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 [email protected]
- ---
* Origin: MadMax BBS - Co-SysOp's Point. (9:9721/210)
------------------------------
Date: Tue, 26 Jan 93 13:56:00 +0100
From: [email protected] (Chris Franzen)
Subject: Mr. BIOS (PC)
> From: [email protected] (Joel A. Frahm)
> I was recently called in to work on a new PC clone, and it had BIOS
> from the Mr. BIOS corporation. And if that wasn't weird enough, this
> BIOS
Hey, MR BIOS (MR is "Microid") is not that weird. It used to spread in
new PC boards in Germany (from Taiwan), until everyone returned back
to AMI. MR BIOS has a superb setup program, and is very well adaptable
to make use of chipset features. The PC integrator I work for (3000
PCs a year) attempted to establish Microid BIOS for all 386- and
486-based boards in the PC line. No success. There were some problems
with exotic OSs like Prologue and UNIX, and there were a lot of
problems with LCD display cards (for portables). So we dropped it and
returned to AMI.
> contains some type of antivirus code, perhaps an MBR protector or
> something.
> Does anyone out there in the real world know anything more about this
> BIOS
> and the ramifications of BIOS based AV software?
The technical dox of the MR BIOS we distributed does not talk about AV
code in the BIOS.
I do know the current AMI BIOS indeed includes MBR protection. They
seem to check if the floppy disk boot sector is being written at
boot-up. (This does not make any sense to me, though.) I believe AV
should not be built into the BIOS ROM since that just animates virus
authors to demonstrate how they can break it.
Chris, The Blast I
- --- GEcho 1.00
* Origin: COMDATA Box, D-2942 Jever, ++49-4461-757442 (9:492/3060@VirNet)
------------------------------
Date: Sun, 31 Jan 93 20:59:00 +0100
From: [email protected] (Inbar Raz)
Subject: ANSI Bombs (PC)
To all of you who are afraid of ANSI bombs, two ways of avoiding them:
1. Replace your ANSI driver. Use something like NANSI, that has a /S
command line switch to DISABLE the keyboard redefinition.
2. If you are a BBS, and using the MTS package, people can infect you by
simply inserting an ANSI bomb to an ARJ COMMENT, and when the MTS
opens the ARJ to its temp dir, the bomb will active.
If you are using ARJ, do this:
SET ARJ_SW=-JA-
If you already have an ARJ_SW, add -JA- to it.
Inbar Raz
- - --
Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 [email protected]
- ---
* Origin: MadMax BBS - Co-SysOp's Point. (9:9721/210)
------------------------------
Date: Sun, 31 Jan 93 21:03:00 +0100
From: [email protected] (Inbar Raz)
Subject: 696 Virus? (PC)
[email protected].Edu (Mark Rauschkolb) writes:
> A co-worker just told me that his home machine is heavily infected byy
> the 696 virus (according to McAfee SCAN). I looked for 696 in the
> VSUM "program" but could not find it.
Did you try locating it through size cross-reference?
It's worked a lot of times for me, especially to identify viruses that SCAN
didn't find.
Inbar Raz
- - --
Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 [email protected]
- ---
* Origin: MadMax BBS - Co-SysOp's Point. (9:9721/210)
------------------------------
Date: Fri, 05 Feb 93 02:59:04 +0100
From: [email protected] (Malte Eppert)
Subject: New virus in Germany :-( (PC)
Hi ALL!
There's a new virus around in Northern Germany which was isolated on the
Fachhochschule Braunschweig/Wolfenbuettel on Feb. 4, 1993. It was analyzed by
Robert Hoerner and has the following characteristics:
- - infects COM and EXE
- - loves infecting COMMAND.COM on drive A:
- - TSR in UMBs (!), stealth
- - uses interrupt trace techniques
- - slightly polymorphic, WHALE and FISH-like
- - uses seconds-stamp for marking infections
- - contains the encrypted text "T.R.E.M.O.R was done by NEUROBASHER /
May-June'92, Germany" and "MOMENT OF TERROR IS THE BEGINNING OF
LIFE"
- - Length: exactly 4000 bytes
The virus is provisorically referenced as "UMB-1 (Tremor)", until a name has
been officially constituted.
Thanks to Robert for his fine work.
cu!
eppi
- --- GEcho 1.00
* Origin: Another Virus Help Node - The EpiCentre! (9:491/6050)
------------------------------
Date: Sun, 07 Feb 93 14:35:48 -0500
From: [email protected] (Paul Ferguson)
Subject: DAME/MtE (PC)
<cssiow@iastate.edu> (Ching S Siow) wrote -
> I would like to find out more about this "DAME Virus".
> My network has 3 files infected with this virus and
> would appreciate some help in cleaning it out. I have
> tried netscan and inoculan, both of which failed to
> discover the virus.
The "Dark Avenger Mutation Engine" (aka DAME ala McAfee
syntax) is more commonly known as the MtE. It is not a
virus, but rather an encryption envelope to which the
virus can be linked. (For more info, see the FAQ.)
If you could be more specific concerning which three
files were suspect and what you used to come to the
conclusion that are indeed infected by a MtE encrypted
virus. I cannot speak for McAfee's NETSCAN (however the
latest versions of their ViruScan detects MtE encrypted
viruses rather well), but we evaluated Cheyenne's Innoculan
NLM withh several MtE encrypted viruses with success.
Paul Ferguson |
Network Integration Consultant | "All of life's answers are
Alexandria, Virginia USA | on TV."
[email protected] (Internet) | -- Homer Simpson
sytex!fergp (UUNet) |
1:109/229 (FidoNet) |
- ---
[email protected] (Paul Ferguson)
Sytex Systems Communications, Arlington VA, 1-703-358-9022
------------------------------
Date: Mon, 08 Feb 93 15:59:02 -0500
From: "David M. Chess" <[email protected]>
Subject: re: Virus scan on a compressed drive (PC)
>From: [email protected] (WONG JIMMY PAK-YEN)
> Presently, when I download some ZIP
>files, I SCAN the disk containing the zipfile, unzip the files onto my
>hard disk, and scan the unzipped files. Will this still work on a
>compressed drive?
I can't speak for any particular scanner except IBM's, but in
general there should be no problem at all here. As long as
the scanner is accessing the files via calls that the
drive-compressor software supports, the scanner will not see
the drive compression at all, and all will go as it should.
In general, any application that uses standard calls to
access files will see the filesystem as perfectly normal
(albeit larger!), if the drive compressor works right.
What might eventually be a problem is that if you do get a
virus infection of some kind, and want to boot your machine
from a diskette to make sure the virus is not active as
you clean up, you'll have to have a special diskette that
installs the drive-compression software, in order to see
the files on your hard disk. That's not generally too hard
to do, but it's probably worth practicing to make sure you
know how to do it and that you have a working diskette that
does it handy. (If you boot from a diskette that doesn't
have the right drivers on it, you'll probably just see your
hard disk as one huge and non-useful file, or none at all.)
- - -- -
David M. Chess | Buy Now
High Integrity Computing Lab | Pay Later
IBM Watson Research |
------------------------------
Date: Sun, 07 Feb 93 19:00:00 -0500
From: Luis Gamero <[email protected]>
Subject: dame virus (pc)
If it's just 3 files, it's probably a false alarm unless you only have 3
executables on disk..:).
- -LG
- --
Canada Remote Systems - Toronto, Ontario
416-629-7000/629-7044
------------------------------
End of VIRUS-L Digest [Volume 6 Issue 22]
*****************************************
|
|
