home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hacker 2
/
HACKER2.mdf
/
virus
/
virusl2
/
virusl2.135
< prev
next >
Wrap
Text File
|
1995-01-03
|
15KB
|
298 lines
VIRUS-L Digest Monday, 12 Jun 1989 Volume 2 : Issue 135
Today's Topics:
Net Hormones: Analysis needed. , Net Hormones Paper by David S. Stodolsky
Re: naming confusion
RE: software industry vs. viruses
---------------------------------------------------------------------------
Date: 11 Jun 89 12:13:31 GMT
From: stodol@diku.dk (David Stodolsky)
Subject: Net Hormones: Analysis needed.
- -----> Net Hormones feasibility: Analysis needed.
- -----> Message forwarded from:
VIRUS-L Digest Friday, 28 Apr 1989 Volume 2 : Issue 102
Date: Fri, 28 Apr 89 11:59:11 MDT
From: Chris McDonald <cmcdonal@wsmr-emh10.army.mil>
Subject: Net Hormones Paper by David S. Stodolsky
-----> (1989a [in references below])
I read with interest the subject paper which resulted in some questions.
First, if contact tracing is technically possible among hosts and
networks, is the proposed "theory of operation" described in paragraph
4 of the paper really practical?
- ----->That is the question. In section 6, "Feasibility and Efficiency,"
Stodolsky (1989a) states:
Contact tracing is probably most effective for sparsely interacting
hosts. The rate of transfer of the infectious agent as compared to
the rate of transfer of the suspect transaction codes is also a
critical factor. Recording of transactions can be comprehensive on
computer networks, however, unregistered transactions will be a factor
in most cases. Once the infectious agent has been identified, the type
of transactions capable of transmitting the agent can be delimited.
This could increase efficiency.
- ----->Someone very familiar with the interaction of hosts on the main
networks and with common infections (maybe the Internet Worm would be a
good case for a start) must look at these factors ( and no doubt others)
before any real estimate of practicality can be made. An epidemiologist
will at least have to check the results, these problems are pretty tricky.
Dr. Stodolsky proposes that: "In the
event that a system is identified as infected, the transaction codes
which could represent transactions during which the agent was
transmitted are broadcast to all other computers." The words "which
could represent transactions" suggests that an attack which used a
delay mechanism or "time bomb" approach would make it extremely
difficult to identify suspect transactions in a timely manner.
- -----> I'll bet that on a net of a million machines, somebody would
set their clock wrong or see the agent by accident if there was a long
delay. I hope the National Security Agency could spot something like
this, at least for their own protection. However, I wonder whether the
pseudonym-based reputation mechanism proposed would give them
sufficient incentive to go public with their discovery.
It might also suggest that the historical record of transactions would
of necessity be inordinately large and for practical reasons might be
difficult to implement.
- -----> Yes, it might. Can you estimate how many megabytes per year
would be required on your system to record all transactions?
Second, even though Dr. Stodolsky stresses that the contact tracing
operation would alert a system to the "possibility" of an agent's
presence, does this represent a significant improvement over other
more conventional means to broadcast alerts of a potential problem, as
is now done over the Internet?
- -----> It represents a better way of reacting to alerts.
Current alerts require human intervention at every system on the net each
time an alert is transmitted. A Net Hormones Receptor Program would filter
out most alerts automatically. The key question here is whether this would
actually reduce the work load of an computer emergency response team.
Current methods might also be too slow in an epidemic.
For example, if I were running a BSD
version of UNIX last November, the tcp-ip broadcast alert--assuming
the gateways were still up and functioning--might have been adequate
to respond to the Internet Worm. If "contact tracing" had been
available, however, would not non-BSD UNIX systems have received
"alerts" which would have caused unnecessary concern?
- -----> The fact that non-BSD systems were not at risk was only
discovered later. If these systems did not receive the tcp-ip
broadcast alert and they had been at risk of infection, then they
would really have been in a bad position. With Net Hormones in
operation, each system at risk would broadcast an non-specific alert,
initially. This might show some pattern of machine or software type.
For instance, with the Internet Worm, there was a sudden large
increase in transactions between BSD machines particularly in the Bay
Area where there is a wide-band network. If this was a substantial
portion of the normal traffic, it could give crucial clues as to what
systems were at risk. In any case, later reports of confirmed
infections would follow. If I were operating a non-BSD system, and
dozens of BSD systems reported infections and not one non-BSD system
had reported an infection, I certainly would begin to think I had
nothing to worry about. What this shows is that some kind of
statistical estimation procedure might be built into the Net Hormones
Receptor Program to avoid unnecessary alarms.
Third, if the alert through contact tracing is to "restrict further
transmission of the agent," is not cutting off communications among
hosts on a network the only practical solution pending further
investigation?
- -----> No, at least it is not obvious. Cutting off communication among
hosts may isolate them from information needed to combat the infection and
prevent further investigation from being effective. If a system was already
infected, then cutting off communication might lead to reinfection of the
net when that system came back on-line. The agent might have already spread
to removable media, such as disks and tapes at that site. A disinfection
program, most easily obtained over the net, would no doubt be needed in
such a case. Asking hundreds, thousands, or millions of systems to stay off
the net until a program is delivered off-line is not practical. Even
arranging transfers of a program over the net by voice telephone, so one
could be sure it was not an infectious agent, seems like an impractical
task, given a large number of systems.
- -----> Also, the sole objective of the infection might be to bring the
net down. Some intermediate response is desirable. In the great New
York power black-out, operators did not drop their connections even
though the conditions indicated that this was appropriate. The
consequences of dropping off the net were considered to be so great
that operators were not really given the discretion to drop their
network connections. Stodolsky (1989a) did suggest the possibility of
dropping off the net momentarily to disrupt ongoing transfers and take
essential precautions.
- -----> If we had, for example, virus like programs that were likely to
destroy worms, we might release them as a programmed reaction to an
alert, while staying on the net to received new information, such as,
that it is a non-BSD worm. The use of benign virii that could
deactivate an invading agent has been suggested (Stodolsky, 1989b).
Others (Odawa, 1989; Platt, 1989a; Youngman, 1989), however, have
objected that no virus is really benign and it would likely cause
damage in some machine - software configuration. Even if we assume
this is true, such benign agents might be temporarily activated, when
there was a risk of major damage from an yet unidentified infectious
agent. Platt (1989b), on the other hand, suggests that custom virii
could be effectively controlled. Certainly a disinfection program that
eventually would be distributed to eliminate the new agent could also
be programmed to clean up any remaining parasitic virii, antibodies,
killer T-cells, or whatever, released during an alert.
Chris McDonald
White Sands Missile Range
- -----> References
McDonald, C. (1989, April 28). Net Hormones paper by David S. Stodolsky.
VIRUS-L Digest, 2(102).
Odawa, M. (1989, May 4). "Benign" Viruses. In Usenet Comp.Virus Conference
(Virus-L Digest, 2[107]).
Odawa, M. (1989, May 12). The only good virus is a dead one. Virus-L
Digest, 2(113).
Platt, D. (1989a, May 8). "Benign" Viruses. Virus-L Digest , 2(110).
Platt, D. (1989b, May 10). Biological analogues. Virus-L Digest , 2(112).
Stodolsky, D. (1989a). Net hormones: Part 1 - Infection control assuming
cooperation among computers [Machine-readable file]. Van Wyk, K. R. (1989,
March 30). Several reports available via anonymous FTP. Virus-L Digest,
2(77, Article 1). Abstract republished in van Wyk, K. R. (1989, April 24).
Virus papers (finally) available on Lehigh LISTSERV. Virus-L Digest, 2(98,
Article 4). (Available via anonymous file transfer protocol from LLL-
WINKEN.LLNL.GOV; File name "~ftp/virus-l/docs/net.hormones": Lawrence
Livermore National Laboratory, Nuclear Chemistry Division and
IBM1.CC.LEHIGH.EDU; File name "HORMONES NET": Lehigh University. And by
electronic mail from LISTSERV@LEHIIBM1.BITNET; File name "HORMONES NET":
Lehigh University).
Stodolsky, D. (1989b, May 4). Virus - worm combinations: A future trend?
Virus-L Digest, 2(105).
Youngman, N. (1989, May 16). Re: The only good virus is a dead one. Virus-L
Digest, 2(117).
Youngman, N. (1989, May 18). Re: The only good virus is a dead one. Virus-L
Digest, 2(119).
- ----->
- --
David S. Stodolsky, PhD Routing: <@uunet.uu.net:stodol@diku.dk>
Department of Psychology Internet: <stodol@diku.dk>
Copenhagen Univ., Njalsg. 88 Voice + 45 31 58 48 86
DK-2300 Copenhagen S, Denmark Fax. + 45 31 54 32 11
------------------------------
Date: Mon, 12 Jun 89 15:02:23 +0300
From: Y. Radai <RADAI1@HBUNOS.BITNET>
Subject: Re: naming confusion
Robert Morey writes (#133):
> Regarding the "PLO" virus and your suggestion that we not call it by
>that name, don't you think that your desire to suppress the link
>between the virus and something which obviously offends you (the name
>"PLO") is a political tactic?
It's unfortunate that Mr. Morey has read a political motive into my
remarks. His claims that I'm "obviously offended" by the name "PLO"
and that I'm trying to "suppress" something are products of his
imagination alone and have no basis in reality. My reason for being
opposed to labelling the Israeli virus the "PLO" virus is precisely
the same reason that I am opposed to labelling it the "DAR" virus, the
"Mongolian" virus or the "Einstein" virus: These names are simply
INAPPROPRIATE. That's really all there is to it, Mr. Morey. Of
course, no one can prevent your imagination from concocting other
motivations. But you have no right to accuse people of them without
evidence, which you certainly don't have in my case since your claims
are false.
> That particular virus is known to many
>people already as the "PLO virus"--now you expect them to have to
>worry about changing that name in their minds because it offends
>someone?
Is changing a name really such a hardship for you? Suppose it
turned out that the story about the Brain virus originating in
Pakistan was merely a rumor, spread by someone with a hyperactive
imagination, that it really originated in Timbuctoo, and never even
spread to Pakistan. And suppose on that basis someone in Pakistan
asked us to stop referring to it as the Pakistani virus. I would
comply immediately. No problem, no "worry". Are you so inflexible
that you can't do the same in the case of the so-called "PLO" virus??
If you're offended by the name "Israeli", you can call it the "Friday-
13" virus, the "Little Black Box", or any of about 8 other reasonable
names. Btw, suppose that someone started calling the Israeli virus
the "Morey" virus and that this name caught on. Wouldn't you feel
like asking people to stop using this name? I wonder if you'd be
quite so sympathetic in that case to the plight of people having to
alter their habits simply "because it offends someone" ....
If you wish to continue this discussion, fine. But if it's anything
more than a one-sentence apology for attributing false motives to me,
mail your remarks to me personally. VIRUS-L is not a forum for poli-
tics or slanders.
Y. Radai
Hebrew Univ. of Jerusalem
P.S. On another subject: In Issue 116 (May 16) I posted a list of
20 PC viruses and asked if anyone has comments to send them to me
personally. It turns out that precisely at that time we had mailer
problems and a lot of mail which was addressed to me didn't reach me.
So if anyone sent me mail and didn't receive a reply, please re-send.
------------------------------
Date: Mon, 12 Jun 89 15:07 EDT
From: Roman Olynyk - Information Services <CC011054@WVNVAXA.WVNET.EDU>
Subject: RE: software industry vs. viruses
My unguarded comment about the hidden text in Microsoft Word Version
1.0 was not intended to be an indictment of the software industry.
This copy is more than six years old, and six years in this industry
is too long to hold any sort of grudge. I regarded this as more of a
curiosity, something for your amusement. To set the facts straight,
however, the statement exists in Word V1.0 for the PC -- at least this
is the version I'm talking about -- not the Mac. The disk that I have
is an *original* of the system disk -- Microsoft Registration No.
301786. The "Trashing program disk" text appears in the file
WORD.COM, disk sector 171, offset 256.
I'm glad that the spokesmen for the software industry are so rabid in
its defense. I'm sure that the American Medical Association, the Bar
Association and any other group is equally as rabid in defense of its
profession. That's fine -- professional organizations should take
such stands. However, let's not get carried away and say that these
things (viruses in commercial software) cannot happen or that
renegades don't exist. They do. So the CEO disavows any knowledge of
such action. There doesn't have to be a conspiracy to sue for
damages. Therefore, I think it's good that the software industry
tries to police itself. I think they should throw the book at and
keel-haul anyone attempting to tamper with legitimate software.
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253