Conference 7.286::digital

Which virus? On which operating system(s)? These 'virus' stories have been
floating about for the past few years. This could be a rehash of an old one or a
new one. Typically, (thankfully), the press doesn't get too technical and reveal
enough details to figure out what operating system it is.

Indeed, viruses are out there- especially in the PC world. Viruses spread
easiest when software (somtimes from dubious sources) is often copied and passed
around- a common practice in the PC world.

Might I suggest you check out the HUMAN::SECURITY_INFORMATION notesfile or
UFP::HACKERS for current or historical information. A DIR/TIT=VIRUS in these
conferences reveals the following topics:

--------------------------------------------------------------------------------
                    Digital Worldwide information on SECURITY
Created: 12-FEB-1986 16:22         255 topics         Updated:  3-NOV-1988 19:42
            -< DIGITAL INTERNAL USE ONLY; policies in note 1.last >-
 Topic  Author               Date         Repl  Title
--------------------------------------------------------------------------------
   157  STEREO::HOLDEN       11-DEC-1987     4  P.C. Virus Warning
   173   TAV02::NITSAN        7-FEB-1988     5  VMS virus?
   236   TUNER::HOLDEN       18-AUG-1988     0  Letter on Computer Virus

--------------------------------------------------------------------------------
                                  ** Hackers **
Created: 31-JAN-1988 22:14         350 topics         Updated:  4-NOV-1988 01:45
                  -< HACKERS V2 - DIGITAL Internal Use Only >-
 Topic  Author               Date         Repl  Title
--------------------------------------------------------------------------------
    12   DIODE::CROWELL       8-FEB-1988    22  Computer Virus'


Lee

[Fresh from UFP::HACKERS. This may also end up being discussed in
HUMAN::SECURITY_INFORMATION. Lee.]

            <<< UFP::SYS$SYSDEVICE:[NOTES$LIBRARY]HACKERS.NOTE;1 >>>
                               -< ** Hackers ** >-
================================================================================
Note 351.0                         New Virus??                        No replies
DNEAST::PFISTER_ROB "I cant put *THAT* here....."     5 lines   4-NOV-1988 08:17
--------------------------------------------------------------------------------

    Anybody have any info on the Virus that was found at Berkley yesterday?
    From the morning TV news, it looks like it was UN*X/ULTRIX that
    was infected. (Lotsa SUN workstations on TV, and methinks, a GPX)
    
    Robb

    This virus was discussed on _All Things Considered_ last night.
    It has invaded the Internet.  I would suggest that any DEC nodes
    which are directly connected to the Internet (if you are, you know
    it, and if you don't know, then you're not) be especially vigilant
    about security until the virus has been eradicated.

[The following is part of RISKS_DIGEST Note 75.0.  It is understood that
 this virus only effects UNIX systems.  According to this note, it could
 not have effected VMS systems.]
--------------------------------------------------------------------------------

RISKS-LIST: RISKS-FORUM Digest  Thursday 3 November 1988   Volume 7 : Issue 69
----------------------------------------------------------------------
 
Date:  Thu, 3 Nov 88 06:46 EST
From: Stoll@DOCKMASTER.ARPA
Subject:  Virus on the Arpanet - Milnet
 
Re Arpanet "Sendmail" Virus attack November 3, 1988
 
Hi Gang!
 
It's now 3:45 AM on Wednesday 3 November 1988.  I'm tired, so don't believe
everything that follows...
 
Apparently, there is a massive attack on Unix systems going on right now.
 
I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem.
 
Symptom:  hundreds or thousands of jobs start running on a Unix system
bringing response to zero.
 
Systems attacked:  Unix systems, 4.3BSD unix & variants (eg:  SUNs) any
sendmail compiled with debug has this problem.  See below.
 
This virus is spreading very quickly over the Milnet.  Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites.  I suspect that well over 50 sites have
been hit.  Most of these are "major" sites and gateways.
 
Method:
 
Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility.  This utility can send a message into another program.
 
Step 1:  from a distant Milnet host, a message is sent to Sendmail
       to fire up SED, (SED is an editor)  This is possible in certain
       versions of sendmail (see below).
 
2:  A 99 line C program is sent to SED through Sendmail.
 
3:  The distant computer sends a command to compile this C program.
 
4:  Several object files are copied into the Unix computer.
        There are 3 files:  one targeted to Sun
                            one targeted to SUN-3
                            one targeted to vax    (ultrix probably, not vms)
 
5:  The C program accepts as address other Milnet sites
 
6:  Apparently, program scans for other Milnet/arpanet addresses and
     repeats this process.
 
The bug in Sendmail:
 
When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it.
 
Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug.
It exists only where the system manager recompiled Sendmail and enabled
debugging.
 
This is bad news.
 
  Cliff Stoll dockmaster.arpa
 
------------------------------
 
Date: Thu, 03 Nov 88 09:52:18 EST
From: Gene Spafford <spaf@purdue.edu>
Subject: More on the virus
Organization: SERC, Department of Computer Sciences, Purdue Univ.
 
All of our Vaxen and some of our Suns here were infected with the virus.  The
virus forks repeated copies of itself as it tries to spread itself, and the
load averages on the infected machines skyrocketed.  In fact, it got to the
point that some of the machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!
 
The virus seems to consist of two parts.  I managed to grab the source code for
one part, but not the main component (the virus cleans up after itself so as
not to leave evidence).  The way that it works is as follows:
 
1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and gets a shell.
 
2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets replaced
 
by the current process id) and copies code for a "listener" or "helper"
program.  This is just a few dozen lines long and fairly generic code.  The
shell compiles this helper using the "cc" command local to the system.
 
3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments).
 
4) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell with
standard input coming from the infecting virus program on the other end of the
socket.
 
From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:
 
5) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  I'm not sure what else the virus does, if anything --
it may also be attempting to add a bogus passwd file entry or do something to
the file system.  The helper program has an array of 20 filenames for the
"helper" to copy over, so there is room to spare.  There are two versions
copied -- a version for Vax BSD and a version for SunOS; the appropriate one is
compiled.
 
6) The new virus is dispatched.  This virus opens all the virus source
files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the virus
steps through the hosts file (on the Sun, it uses YP to step through
the distributed hosts file) trying to connect to other machines'
sendmail.  If a connection succeeds, it forks a child process to infect
it, while the parent continues to attempt infection of other machines.
 
7) The child requests and initializes a new socket, then builds and invokes a
listener with the new socket number and hostid as arguments (#1, above).
 
The heavy load we see is the result of multiple viruses coming in from multiple
sites.  Since local hosts files tend to have entries for other local hosts, the
virus tends to infect local machines multiple times -- in some senses this is
lucky since it helps prevent the spread of the virus as the local machines slow
down.
 
The virus also "cleans" up after itself.  If you reboot an infected machine (or
it crashes), the /tmp directory is normally cleaned up on reboot.  The other
incriminating files were already deleted by the virus itself.
 
Clever, nasty, and definitely anti-social.  
 
--spaf
 
------------------------------
 
Date: Thu, 3 Nov 1988 14:27:22 PDT
From: Peter Neumann <neumann@csl.sri.com>
Subject: More on the virus attack
 
Remember that the above are preliminary messages relating to an event in
progress.  There seem to be many unanswered questions.  Perhaps someone will
contribute a definitive report to the next issue of RISKS.
 
Examination of the code suggests a fairly sophisticated person writing
relatively high quality (although undocumented) code, exploiting several flaws
that exist(ed) on many UNIX systems, and written with considerable good
practice in self-checking, reliability, etc.  From the evidence thus far, I
would guess it that this was a deliberate attack, not an accidental experiment
run astray. 
 
Although it was primarily a denial of service attack, it did some remarkable
things, taking advantage of many different approaches.  The spawned
processes appear to have been doing attacks on encrypted passwords to enable
ftps (in case the .rhost attack would not work -- cf. the Stanford breakins
described in CACM and SEN by Brian Reid).  Separate versions to run on Suns
and Vaxens were apparently propagated in DES encrypted form, decrypted, and
both programs tried to see which one would work.
 
We quoted Henry Petroski here over a year ago to the effect that we do not
learn from our successes, but that we have an opportunity to learn from our
failures.  Once again we are presented with the opportunity to learn that many
of our computer systems have serious security vulnerabilities, and that we need
to take pains to defend against the really malicious attacks.  Strangely some
people take heart in the fact that the security attacks to date (whether
penetrations, exploitations of privilege, Trojan horses, or legitimate viruses)
have been relatively modest in scale, perhaps to justify the absence of
concern.  I am afraid that it will take a Chernobyl- or Three-Mile-Island-like
disaster before the community at large wakes up.  PGN
 
------------------------------
 
Date: Thu, 3 Nov 88 16:32:25 EST
From: bishop@bear.Dartmouth.EDU (Matt Bishop)
Subject: More on the virus
 
...  This program introduced itself through a bug in sendmail.  At these sites,
sendmail was compiled and installed with a debugging option turned on.  As near
as I can figure (I don't have access to the sendmail sources), by giving a
specific option to the "debug" command in sendmail (there are lots of those,
controlling what exactly you get information about) you can cause it to execute
a command.  As sendmail runs setuid to root, guess what privileges the command
is executed with.  Right.
   Apparently what the attacker did was this:  he or she connected to sendmail
(ie, telnet victim.machine 25), issued the appropriate debug command, and had
a small C program compiled.  (We have it.  Big deal.)  This program took
as an argument a host number, and copied two programs -- one ending in
q.vax.o and the other ending in .sun.o -- and tried to load and execute them.
In those cases where the load and execution succeeded, the worm did two things
(at least):  spawn a lot of shells that did nothing but clog the process table
and burn CPU cycles; look in two places -- the password file and the internet
services file -- for other sites it could connect to (this is hearsay, but I
don't doubt it for a minute.)  It used both individual .rhost files (which it
found using the password file), and any other remote hosts it could locate
which it had a chance of connecting to.  It may have done more; one of our
machines had a changed superuser password, but because of other factors we're
not sure this worm did it.
   This last part is still sketchy; I have the relevant sun.o file and will
take it apart to see just what it was supposed to do.  As of now, it appears
there was no serious damage (just wasted CPU cycles and system administrator
time).
   Two obvious points:
1.  Whoever did this picked only on suns and vaxen.  One site with a lot
    of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
    but the attempt to get the other machines didn't work.
2.  This shows the sorry state of software and security in the UNIX world.
    People should NEVER put a program with debugging hooks in it, especially
    when the hook is (or can be made) to execute an arbitrary command.  But
    that is how the sendmail which was used was distributed!
   One more interesting point:  initially, I thought an application of the
"principle of least privilege" would have prevented this penetration.  But
the attacker used a world-writeable directory to squirrel the relevant programs
in, so -- in effect -- everything could have been done by any user on the
system!  (Except the superuser password change, of course -- if this worm
did in fact do it.)
   I think the only way to prevent such an attack would have been to turn
off the deug option on sendmail; then the penetration would fail.  It goes to 
show that if the computer is not secure (and like you, I don't believe there
ever will be such a beastie), there is simply no way to prevent a virus (or,
in this case, a worm) from getting into that system.
   I know this is somewhat sketchy, flabby, and fuzzy, but it's all I know
so far.  I'll keep you posted on developments ...
 
Matt
 
------------------------------

        If someone can explain to me what this topic has to do with "The
        Digital Way of Working", I will make it WRITEable again. 
        
        If someone can explain to me why cross-postings of material from
        other conferences (which are more appropriate to this matter)
        should be left here, I will not delete them.  (Pointers to
        relevant discussions are always welcome; cross-postings of bulk
        material generally are not.) 
        
        Otherwise, this topic will be left write-locked, and will be
        deleted from the conference in about a week. 
        
        Please send me MAIL if you wish to provide explanations.  Please
        do NOT start another topic. 
        
        Thank you.
        
        Tom
        co-moderator

        I've received a number of MAIL messages concerning my action
        in "write-locking" this topic, and I'd like to explain why
        I did it, and apologize to any who felt my tone was abrupt.
        
        The charter of this conference, in the broadest sense, is to
        discuss "the Digital way of working".  This is a very broad
        charter, and encompasses a lot of ground.  However, it does
        not include certain things, which, in my opinion, include being
        a general question-and-answer conference (ANYWAY::ASKENET has
        that as a broad charter), or being "rumor control central".
        
        More than one person asserted that the recent computer virus
        should be discussed here, because it's important to control
        any rumors about the virus.  I am not swayed by this argument,
        since I firmly believe that people with accurate information
        are much more likely to be discussing the problem in the many
        conferences that specifically address such matters.
        
        One person suggested that people in the field would be able
        to use things they read in this conference to discuss the recent
        virus with customers or the press.  This would be completely
        inappropriate.  Everything in this conference is intended for
        Digital Internal Use Only, not for disclosure to customers
        or the press.
        
        One person implied that this conference belongs to the moderators,
        not to the participants.  Nothing could be further from the truth.
        You all have my humble apologies if my actions, or those of any of
        the other moderators, have lead you to feel that way.  Moderators
        sometimes try to lend a guiding hand, in the hope of making the
        conference more valuable to all participants.  We're not perfect,
        and we sometimes err.  
        
        Several people did make some good points, however, and having
        considered them, I'm re-opening this topic, with a new title.
        I'd like to ask that people pursue specific technical points
        in the conferences that are more relevant to them, such as:
        
        NAC::ULTRIX		In particular, see topic 562 for info
        			on this particular "virus" incident
        
        HUMAN::SECURITY_INFORMATION
        			Security topic in general
        
        HUMAN::SECURITY_POLICY
        			Software security policies
        
        ANCHOR::EASYNET		Digital's EASYNET
        
        LASSIE::ARPA_INTERNET	ARPA Internet protocols, perhaps other
        			Internet topics as well (the SENDMAIL
        			program that proved to be the loophole
        			implements an Internet protocol)
        
        BEING::GATEWAYS		Gateways to other networks, esp. our
        			official gateway to the Internet
        
        RAHAB::SOAPBOX		Free-ranging discussions on almost
        			any topic your heart desires, with
        			few if any holds barred
        
        UFP::HACKERS		Technical discussions of viruses and
        			related matters, by those in the know
        
        I'm sure there are others as well.
        
        Another useful source of information is the "Risks Digest"
        conference at SNDBOX::RISKS_7.  An extract from that conference
        was posted as an earlier reply here; I suggest you check topics
        there for informed commentary from the outside world.

        Please keep discussions here to matters that reflect on how the
        need for network security impacts the way we work at Digital. 
        
        Please use the other more focused conferences for the specific
        details of various aspects of viruses, both this recent one in
        particular, or the broader question. 
        
        I'm including here an (unattributed) extract from one MAIL
        message I received; it suggests some questions we might consider
        here, and some guidelines that I think are reasonable.
        
>       I fully intended on Friday night to ask questions in the DIGITAL
>       conference like: 
>
>       "...would this cause our higher level management to disconnect
>       DECWRL from the outside world?..." 
>
>       and 
>
>       "...if something like this can happen in the outside world, can it
>       be considered justification to begin disconnection and
>       decomposition of our E-Net in order to shield our own computers
>       from hackers inside DIGITAL?..." 
>
>       I agree with your comment about pointers to other conferences.
>       However, there are questions like these, that I think would be
>       fielded better within the DIGITAL conference, over the HACKERS or
>       ARPA-INTERNET conferences. Those are both primarily technical
>       conferences, and don't have the kind of general composition of
>       noters that the DIGITAL conference has (although I have other
>       reasons for feeling this way). 
>
>       Information about this virus can now be found in many other
>       conferences. I would personally like to see replies to DIGITAL
>       note #655 which point to the conferences and their specific note
>       numbers, with the selection options set to add those conferences
>       to a user's notebook. 
>
>       Perhaps you could re-create the base note with these kinds of
>       "rules" governing the replies so that people know if they
>       cross-post an entire set of text, they will get the reply sent
>       back to them? 
        
        Sounds reasonable to me.  I'm setting this topic writable once
        again.  Please try to focus on how viruses and the need for secure
        data networks impacts the way we work at Digital, and not on this
        specific instance of a virus.  Please point us to relevant
        discussions in other conferences, and provide a brief summary of
        those discussions if you feel it's helpful, but please do not
        cross-post large extracts from other sources. 
        
        Your humble servant,
        
        Tom

    I would have thought that there would have been a little more
    discussion of this topic here, due to the possible impact that a
    virus could have on our own network.
    
    Sometimes I think that we, in DIGITAL, take our network for granted.
    I suppose that's why we call it EASYnet, because it's so easy to
    communicate and get work done through it.
    
    I wonder what the reaction of upper level management would be if
    someone within the company unleashed a virus on the network.  My
    main concern is that it might be shutdown.  Most likely, we would
    become more IBM-like and start placing access restrictions everywhere.
    
    I would site one example of this...there is "feature" to the Phone
    Utility that allows people to send messages to people on other nodes
    without those other people knowing where the message came from.
    (This "feature" is, or at least was documented in the Hackers
    conference.)  This is why, on some EASYnet nodes, you cannot connect
    to the Phone Utility.  The system managers for those nodes simply
    removed the Network Object for the Utility, in order to prevent
    this.
    
    Imagine how useful the Phone Utility would be if it was removed
    from *ALL* EASYnet nodes because of this...but, that's only Phone.
    Remember that the UNIX virus was transmitted through E-Mail.  It
    would be a real drag if someone found a similar loop-hole in our
    Mail system, and decided to exploit it in the same way.
    
    Just a thought...
    
    Doug

    RE: .10
    
    Doug, one minor correction on your "phone" feature.  You can tell
    who is sending the message across your screen, only you need to
    check the DECNET logs to see who did the PHONE connection.  Most 
    people don't know how to do this, so they assume they can't tell
    who is sending the flash across the screen.
    
    The reason some system managers have disconnected the PHONE utility
    is because of security reasons not related to the feature you
    described.
    
    
    Gale

    RE: .10 Yes it is possible to hack the PHONE and even the MAIL-11
    protocol to send 'anonymous' messages. (I received one such mail
    message last week.) A quick check of the accounting log or even
    NETSERVER.LOGs is usually all that it takes to find out the real
    sender. (Which is what I did.) The biggest reason that PHONE
    doesn't work is that the node name you give it is a cluster alias
    and PHONE doesn't work with a cluster alias.

    I don't believe that DEC would shut down the net if a worm like the
    one that hit Unix systems got lose. KO came out pretty supportive
    of networks and open communication in both the print and TV media.
    He was asked about the recent worm (it wasn't a virus). I think that
    it might make a few more system managers a bit more serious about
    security. I think that it would make some development groups a bit
    more careful about back doors and the like. Over all I don't think
    it would make a big difference.

    		Alfred

    Please don't hypothesize or speculate what the consequences of a
    massive security failure of the EASYNET would result in.

    It's very easy for such a discussion to be pulled out of context and
    interpreted as follows: since there's discussion and since "they" would
    never admit that it happened, it "must" have happened.

    By the way, the publicity associated with the shutdown of this computer
    network, touted as the world's largest by some measures, designed,
    operated, and used exclusively by the world's leading vendor of
    networked computer systems, would figuratively bury Digital.

	If I remember correctly, we have had virii loose on the EASYnet.  They
    were killed with great dispatch and a minimum of inconvenience.  So much
    dispatch that the majority of people were not even aware that a problem had
    occurred.  The fact that this has happened was not advertised, but it has not
    been suppressed either.  The exact details have NOT been published for
    obvious reasons.  I think the Corporate Telecommunications people who have
    kept the EASYnet clean deserve a vote of thanks. 

    
    	     What is not so obvious or self-evident (unless you are
    a system manager) is that there are a *LOT* of people and resources 
    involved in constantly testing the EASYnet, looking for incorrectly 
    protected files, illegal DECnet objects, easily guessed passwords,
    etc. 
    
    Several software security packages are in use throughout the network, 
    solely for the purpose of keeping our systems, and the EASYnet secure.
    There is even a central group of people dedicated to JUST security on the
    EASYnet.
    
    Having the same thing on the ARPAnet would be much more difficult
    since there you must deal with multiple companies and environments.
    
    
    							Warren
    
    

>    By the way, the publicity associated with the shutdown of this computer
>    network, touted as the world's largest by some measures, designed,
>    operated, and used exclusively by the world's leading vendor of
>    networked computer systems, would figuratively bury Digital.

Then we better be really quiet about last weekend.

/john

    re .16:  Good advice, but probably too late.  Old Chinese proverb:
    If you don't want people to know what you have done, you shouldn't
    have done it in the first place.
    
  --Simon
    

    RE: .19
    
    The author of the note set the note hidden, not the moderators.
    If the author decides to unhide his note, then either he or we will.
    
    Gale Kleinberger
    co-mod

        And the note is now un-hidden.

    Re .12
    
    Alfred, I have heard of `worms' and now the public term `virus'.
    Until I read your note, I had used the terms synonomously with 
    preference given to `virus' because of the publicity.
    
    Is there a difference, and, if so, what is it?
    
    Thanks

I believe the difference is that worms are not destructive, and don't 
leave any trojan horses, etc., behind.

    A virus is part of an other program. As such one may copy it
    and use it with out knowing that there is a 'nasty' in it. A
    worm is a stand alone program that moves itself around though
    it may take advantage of security holes in other programs to
    speed it's progress.

    The little utility that you use for months and then one day
    deletes all your files has a virus. A program that copies itself
    all over the net until it bogs everyone down is a worm.

    			Alfred

Your definition of "virus" was previously called a "trojan horse."

/john

    If I understood it correctly, a computer virus is a program that
    attaches itself to some existing codes while a worm does not affect
    other programs.  Incidentally, a computer virus is a lot like a
    biological one in that the biological virus replaces the DNA in the
    cell.
    Eugene

    This is getting of the subject, the querie would perhaps be best
    answered in another conference, perhaps UDP::HACKERS.
    
    Mark

    When moderators engage in it, it is NO longer a rathole.

	A rat hole is a rat hole. The difference between a virus and a
	worm is a nit. I was just trying to answer a question but it
	is not a big enough deal or related enough to the discussion to
	go on for ever about. At least not in this conference.

			Alfred

	This is from a page 1 article, the third and final part of a
	series on computer security entitled "System sabotage: A
	matter of time":

	"Still, the few publicly known cases shed light on the virus
	problem:

	...

	o Digital Equipment Corp. has been hit by a series of small
	and rather benign viruses in its 30,000-terminal electronic
	mail network, the largest in the world. Digital insiders say
	one virus, called "turkey", threatened to erase files but did
	not.
	
	Some of Digital's customers, including companies doing
	business with the National Aeronautics and Space
	Administration, were hit nearly 14 months ago by computer
	hackers from Hamburg, West Germany. Some of these intruders
	bypassed Digital's operation system security, read the
	password list and planted one or more viruses in the system,
	according to NASA officials. No classified material was
	affected, and Digital quickly sent out programs to patch the
	holes in its software."

        I found the attached letter from Richard Stallman, which was
        published in today's Boston Globe, apropos to this discussion.
        
        While I don't agree completely with his position, there is some
        food for thought here. 
        
        There is what I will call a "social contract" that suggests one
        should not enter another's home, even if the door is unlocked,
        unless one has been invited.  But does the same rule apply to,
        say, a government office building?  (After all, the public owns
        the government buildings.)  [Note:  Your tax dollars pay for the
        Internet, DARPA, LLNL, etc.] 
        
        Is there truth to the old saying that "Just because I'm paranoid
        doesn't mean they're not out to get me!"?  Is it a good basis for
        public policy, or more significantly, legislation? 
        
        Tom
        
        
                      The Computer Hacker Hysteria
                           by Richard Stallman

                  {From the Boston Globe, 29-Dec-1988}

Imagine that a person enters a building through an unlocked door, harms
nothing, and leaves through another door, unlocking it behind him.  Imagine
that he does this several times, never causing injury or damage, just some
muddy tracks on the linoleum. 

Imagine that the media call this an "invasion", and the building a
"target" (presuming a violence that did not occur).  Imagine that the
superintendent wonders "what he wants" (implying some sort of intended
extortion) and how to contact him "before" he starts destroying things --
but does not lock the door. 

We would say that this is biased reporting, smearing a harmless person for
things he clearly is not inclined to do. 

But replace the building with a computer at Lawrence Livermore National
Laboratories, and you will get the tone of recent articles and radio
broadcasts about the Internet worm program. 

Many of the articles dwell on the destructive things such a program could
have done, and make its author sound like a nasty person, although he
designed the program not to do any of those things.  They may mention that
the damage from the worm, which resulted only from overloading the
network, appears to have come from a minor programming error, but they
demand his prosecution as if it were deliberate sabotage. 

It appears that people are working themselves into a state of anger at
events they imagine might happen.  But there is no way to punish the
culprits of hypothetical crimes, so they will vent their frustrated anger
on the people who inspired their imagination. 

The Livermore staff members were more sensible; they asked the visitor to
communicate with them.  Once in communication, they could come to terms on
a friendly relationship.  But they nearly spoiled this wise plan by
presuming his hostility at the same time -- by calling his visits
"attacks", and implying that he was likely to act destructively.  The news
reporters picked up this spirit and ran with it. 

If the staff were afraid the visitor meant harm, even though he had shown
no sign of this, he had to be more afraid of them after the news articles. 

Last fall a German security-breaker was lured to France under the pretense
of an invitation to speak; on arrival, he was arrested.  If the visitor
did phone, would the call be traced?  Did the Livermore staff members plan
to sham friendship and arrest him?  They did not, but the visitor couldn't
be sure. 

Luckily, the Livermore story had a happy ending.  The staff members were
friends with someone who knew the visitor, and he convinced the visitor
that it was safe to call.  It turned out that the visitor, like most, just
wanted to learn about the computer network. 

Livermore has suffered from the recent law that makes unauthorized use of
the computer a crime.  The staff had to spend hours persuading the FBI to
agree not to prosecute anyone who had not intended to cause harm.  This
law causes trouble for every sensible computer-system manager who would
rather establish trust than threaten and fight. 

We can suppose that the public is worried that if this person has an
opportunity to do harm, another person might do it.  Steps to prevent such
damage are sometimes justified.  But it is against American standards of
individual justice to condemn this visitor for the crimes he chose not to
commit. 

[Richard Stallman, a former staff system developer at MIT, is president of
Free Software Foundation in Cambridge, MA.] 

    In the realm of National Security, this is a *VERY SCARY* idea this
    fellow is putting forward.
    
    It's almost like saying: "I unintentionally left the door unlocked,
    so you are now allowed to come on in and handle anything you want."
    
    In the military there is a concept called OPSEC.  It stands for 
    operational security.  One of the precepts of this concept (don't
    you love it when I get cerebral?) is that an organization may have
    many dis-associated pieces of information, which separate, are
    unclassified (classified meaning confidential, secret, top-secret,
    etc).  However, when some of these pieces are put together, like
    putting together a puzzle, the end result may be very classified.
    
    This concept can be carried directly over to the private sector
    also.
    
    The bottom line is that even if a person has no intention of leaving
    muddy tracks on the floor or causing any physical destruction while
    in the building, s/he may have an opportunity to read some papers left
    out on desks in unlocked rooms.  Enough of the *RIGHT* papers could
    be the basis for *SERIOUS* destruction after the fact.
    
    Doug
        

        Ah, but Doug, I think you're begging the question.  Whose job
        is it to make sure the door is locked, and that the papers
        aren't left out on the desks?  Who is at fault?  Is it the
        person who wanders through and happens to see the papers, or
        is it the person who left the doors (routinely) unlocked?
        
        As I said, I don't think Stallman's position is universally
        defensible.  But his point that when you leave the doors open
        you have a hard time claiming that anyone found inside is a
        trespasser is a valid one.
        
        I'll point out that I personally consider most "national security"
        arguments to be specious at best, and malicious at worst.  In my
        opinion, they usually reflect paranoia, not a healthy concern for
        protecting something valuable. 
        
        Tom

>        But his point that when you leave the doors open
>        you have a hard time claiming that anyone found inside is a
>        trespasser is a valid one.
    
    And that's the sad part.
    
    If it's not yours, don't touch it.  Personally, I don't cut through
    people's yards, wander into buildings that I don't know I belong in,
    etc.  Doesn't being responsible for your actions mean anything anymore? 
    The more and more that idea is deemphasized, the less people are going
    to worry about whether what they do has any detrimental effect on those
    around them.  "Hey, if you can do it, it must be legal, right?"
    
    I'm not hardlining trespassing with the idea that trespassers should be
    lined up and shot.  Merely that trespassers should be responsible for
    the act of trespassing.  Too bad the notion of common sense doesn't
    hold up anymore.  We don't have anything 'common' anymore for everyone
    to base judgements on.
    
John

    I also disagree with the concept that equates taking advantage of
    unintentional lapses of security to "leaving the doors open".
    
    I've been following Stallman's missives for many years now, and I
    spoke to him in 1980 for about 45 minutes, after which I was convinced
    he did not live in the same world as I.  His ethics, seemingly shared
    by most of the "crackers", scare the heck out of me.
    
    
    A sad side-note observation - today's issue of "USA Weekend", a
    syndicated newspaper magazine, has a "movie poll" in which they ask
    readers to "vote" on various topics, including which real-life person
    should have their story made into a movie.  One of the candidates was
    "The whiz-kid who unleashed that monstrous computer virus." 
    Whiz-kid?  Fooey!
    
    				Steve
    
    "

    
    I think that the concept of common sense (mentioned in .-2) is really
    important here.  Common sense or "social contracts" are created
    and adhered to so that people don't have to spend all their time
    defending their property, they can spend their time on more creative
    pursuits.  Entering an unlocked house and leaving nothing but a
    footprint is not a violation of a law, but it *is* a violation of the
    social contract that says my house is a place where I can do what
    I want without worrying about intrusion because I'm not going to
    waste my time trying to enter your house.
    
    Civilization depends on our keeping these agresments with each other.
    The agreements are trivially easy to violate, but keeping them means
    neither of us waste our time and energy on defense (or agression)
    but can devote ourselves to creative pursuits that benefit all
    of us.  
    
    I'm sure that most of the readers of this notesfile could easily
    "hack" some secure system if they chose to do so.   Most of us don't.

    An atmosphere of technical anarchy (which is what the "unlocked
    door" argument suggests to me) looks like creative freedom from a
    distance.  But it turns out to be more restrictive when you get
    up close since you're devoting all your time and energy to boundary
    protection.  And creative people shouldn't have to do that.
                        
    Maybe the problem is that large computer networks aren't yet perceived
    of as social systems, and they ought to be.    The "whiz kid" mentioned
    in .-1 perhaps should be honored for his creative intelligence,
    but not for his having knowingly violated a social pact.
    
    Wendi

re: Stallman:

Richard practices what he preaches -- his files are open to all (and many
people know his login password).  I'm pretty sure he recognizes the need
for secure systems, but his message is "if you want it secure, make it
secure: don't just say 'secure' and hope noone notices."

I think the real problem is the lack of ethical training/behavior among
people with the skills and tools to break into systems.  There are several
hundred locksmiths in Boston, each with the tools and skills to walk through
my front door, but I don't worry about them, and would have a difficult time
convincing an insurance company that a locksmith robbed my house.

What do locksmiths know about ethical behavior that university graduate
computer programmers don't?

Martin.
  
Ps: Some definitions:

virus:		evil program that attaches itself to an unsuspecting
		application or disk.  (Infected programs have been found
		on non-Dec CD-Rom collections.)  (I haven't seen any of
		these on VMS, though I don't doubt they might exist.)

trojan horse	program developed to intentionally have a benign user-visible
		portion (typically a game) and an evil purpose (delete all
		files or grab passwords).

worm		craws around networks.  May have virus (etc.) aspects.

    I heard on the 6 o'clock news (Channel 7, Boston) that three new
    words are being added to Webster's Dictionary:
    
    	Computer Virus
    	Televangelist
    	Colorization
    
    The commentator went on to explain that "a computer virus is [...] by
    worming it's way into other computers". Right. It'll be interesting
    to see what actually ends up in Websters.
    
    -Glenn- 

re .40

Which Webster's?

    Re .38, others:
    
>    Entering an unlocked house and leaving nothing but a
>    footprint is not a violation of a law, but it *is* a violation of the

    As a matter of fact it *IS* a violation of a law to walk into an
    unlocked house uninvited.  It is called illegal entry and its one
    of the real problems with Stallmans analogy.
    
    Furthermore the owner of property does NOT have to insure the security
    of that property to be protected under the law.  They only have
    to make reasonably clear that wandering around is not welcome.
    
    For instance, owners of unattended land do not need to construct
    unbreachable walls with spotlights and guard towers, they do not
    even have to put up a fence.  All they have to do is put up 
    "NO TRESPASSING" signs on the borders of their property were they
    can be seen.  If you then choose to go onto that property anyway,
    "because they have not really made it secure", then, no matter what
    your intent you are doing while you are there, you are guilty of
    trespassing.
    
    --  Barry

    Speaking of viruses and the like,
    
    There is a series of messages going around on Fidonet in the "MEADOW"
    conference about how a virus implanted itself onto the carrier detect
    circuits of his 2400 baud modem.  With this virus in place, all
    files that pass thru the modem are "infected", and everyone who
    has a 2400 baud modem is subject to infection, due to the carrier
    detect circuit.  Only people with 1200 baud modems are safe from
    this virus.
    
    The bottom line here is that probably something broke on this guy's
    PC, which is running his BBS system.  The breakage caused his hard
    disk to become corrupt, and lose some large quantity of downloadable
    files.  So, with all the paranoia of computer viruses, he attributed
    his corruption to a virus that infected his modem.  Of course, he
    had no backups either.
    
    Wish I still had a copy of that message - it was hilarious, and
    it wasn't April Fool's Day, either!
    

    Consider the possibility of treating an "unguarded / unprotected"
    computer system as an "attractive nuisance".  An attractive nuisance
    is something that can attract children (like an unfenced construction
    site).
    
    If you have an attractive nuisance, it is your responsibility to
    keep children out.  You're liable if one is injured.
    
    I would apply the same rules to computer systems (and make the value
    judgement that many "hackers" == children, if not literally, then
    effectively).
    
    /s/ Jim Williams

    re .44  
    
    I know of no computer hacker who has been physically injured or
    placed in physical danger by a unsecured computer.  (I understand
    that there will be tries to make scenerios where this could be proven
    wrong.  Please don't.)
    
    The "nuisance" aspect of those laws is based upon the assumption
    that someone who does not know better could injure themselves. 
    If someone manages to fall into a swimming pool, all I suffer is
    the inconvience of fishing them out.  
    
    -kevin
    
     

    Ref: .37 and .38
    
    I totally agree with .37 about the story in 'USA Weekend'.  The
    people in the US have gone bonkers to think that the guy who broke
    into the systems with a virus is a genius and a movie should be
    made about him.  There are thousands of us out here who can do the
    exact same thing, but ethically are bound to not do it.  Anyone
    can pull a gun on a bank teller, but only the ethically deficient
    do it.  Then we make a movie about it as if it was something
    incredible.  Are we going to raise (lower?) hackers to the same level.
    It is time we educated the public so they realize that there is
    no mystery, JUST LOGIC, to computer programming.  Then flush the
    undesirables out and please do not glorify them with the title 'whiz
    kid'.  The fellow is no programming wizard, and as a grad student,
    no kid either.  Just a bit bucket with no ethics...........
    
    Ex-Hacker from the sixties and seventies,
    
    Chat
    

    RE: .42
        
>>    Entering an unlocked house and leaving nothing but a
>>    footprint is not a violation of a law, but it *is* a violation of the

>    As a matter of fact it *IS* a violation of a law to walk into an
>    unlocked house uninvited.  It is called illegal entry and its one
>    of the real problems with Stallmans analogy.

    You have to be careful about statements like this; the trespass
    laws vary *greatly* from state to state.  Most states require either
    proof of malicious intent or proof of repeated acts before you can
    secure a trespassing conviction.  And even then, trespassing is
    almost always classified as a misdemeanor, or "petty crime".

    The hysteria being generated about hackers and network break-ins
    has prompted lawmakers to whip out some legislation that in some
    cases is unenforceable, and is mostly muddled and vague at best.
    Some of these "computer security" laws are sure to come back and
    haunt us later on ...
    
    I don't have any pat answers, except to say that the rapid pace
    of technological advancement will always make it difficult to keep
    tight security on computer networks.  As any cryptographer will
    tell you, anything that one man can come up with, another can break.
    
    "Secrets are fleeting at best, and the most closely guarded secrets
     are often the most fleeting of all ..."

    Geoff

You people keep comparing this to walking into an unlocked house.

BULL!  We have passwords.  These are our "keys" for our locks.
Would this person entering a house be guilty of something more
that a "petty crime" if he picked the lock?  Of course he would!

What in the hell do you think passing a dictionary of commonly
used passwords is?  It's like toting a portable locksmith.

This guy BROKE IN.  Not "wandered in", he plain old BROKE THE
LOCK!  Why is this so hard to see?

/harv

>This guy BROKE IN.  Not "wandered in", he plain old BROKE THE
>LOCK!  Why is this so hard to see?

Not quite.  He came in through a door where the lock was broken.

He also (mostly) invaded public "buildings" or those parts of private companies
working on publicly funded research projects.

/john

>>>  He also (mostly) invaded public "buildings" or those parts of private 
>>>  companies working on publicly funded research projects.
    
    Is the above the same as shoplifting in a public store since it
    really hurts no one except some 'public' (read unknown) entity.
    I agree that our passwords are locks, some may be simple just as
    not all locks are like bank vaults, but no one has to right to 'pick'
    at a password.  Like I said earlier, we can all write programs to
    randomly auto-dial, keep a log of answering tones, etc., etc.  Ethics,
    not just laws, will keep us clean.  I am reminded of a Time cover
    story of about a year ago titled "Whatever happened to ethics in
    America?".  Yes, what has happened?  We now live in a country where
    Ed Meese-ism rules......he left the office unindicted.  If you are
    not caught breaking into a computer, then you are clean.  What a
    pity.
    
    Chat

>>>  He also (mostly) invaded public "buildings" or those parts of private 
>>>  companies working on publicly funded research projects.
    
>    Is the above the same as shoplifting in a public store since it
>    really hurts no one except some 'public' (read unknown) entity.

Of course not!  If you can't see the difference between going into a public
(government) building and stealing from a private store, we have no basis for
discussion.

Back before we had terrorism problems, and when I was a teenager, I used to go
ALL OVER the U.S. Capitol building and the Pentagon -- essentially anywhere
except areas posted as having restricted access.

The Architect of the Capitol even gave me detailed enough plans to be able to
find my way through huge air ducts in the basement.  Most public buildings
continue to be open to the public, although more parts of the buildings are
restricted because of bomb threats.

/john

>    I agree that our passwords are locks, some may be simple just as
>    not all locks are like bank vaults, but no one has to right to 'pick'
>    at a password.

I agree with you 99.44% on this.  I don't consider looking to see if there is
a "GUEST" or a "USER" account with an obvious password to be picking a lock,
I consider that to be a *REAL* welcome mat.

The famous Morris computer virus did not require guessing passwords; it walked
through an open back door which was not protected by any lock or password.

/john

    Background:  Stallman invented Emacs and gave it away.  He doesn't
    think anyone should ever have to pay for software.  

>The famous Morris computer virus did not require guessing passwords; it walked
>through an open back door which was not protected by any lock or password.

The backdoor via sendmail was the primary mode of access.  A password
guessing scheme was also employed to further the progress of the worm.

Walt

Perhaps a fitting punishment would be to require the criminal to write
a personal letter of apology to each of the 6,000 system managers whose
system was affected.

"Write," as in "write in longhand, on a piece of paper"

Martin.

re .54

Yep, I'll agree that as soon as the password-guessing began, that would have
been the same as if I had started poking at cipher-locks in the Pentagon.

Until then, he was just walking the halls.

/john

>The famous Morris computer virus did not require guessing passwords; it walked
>through an open back door which was not protected by any lock or password.

    Actually the 'Morris Virus' was more the moral equivilant of climbing
    onto the roof, opening an unlocked window, and crawling through.
    
    ...and then accidentally blowing all of the fuses in the building.

    RE: .-1
    
    	One thing was skipped in the "accidental fuse blowing" example
    	in the previous reply. The person who climbed the roof, opened
    	the unlocked window and crawled in "..accidently blowing all
    	of the fuses in the building.." was trying to leave something
    	unauthorized in the house. Sort of like planting a bug. If the
    	fuses hadn't blown, something would be in the house now, undetected, 
    	left by the intruder.
   
    							Warren
     
    

Re Morris's worm:

	If it had only entered the system by a back door, I would have less
    trouble (but not no trouble) with it, but it did try to 'pick locks' (guess 
    passwords) and 'climb in upstairs windows' (corrupt the program stack) and
    it did not walk back out (kill itself after some period of time).

Re the SPAN worm:

	The reaction seems to be slightly overblown but does point up two 
    serious DECnet problems -

    1.	The default DECnet account has a very bad default password on it and 
	the method for generating it should be changed.

    2.	The TASK object should be much more closely controlled than it is.
	(My personal opinion is that it should have an invalid password set
	for it and not be deleted since it has a number of valid uses.)

	However, the fear expressed in the articles that files might have been
    deleted is a little misdirected.  Provided no other security holes were used
    to gain additional privileges, the only files that the worm could have 
    deleted are the same files that could have been deleted via remote access.
    That is, no important files could have been deleted by the worm unless the
    protection on those files had been set or reset improperly to begin with.

	There is at least one other technical issue with the newsgroup posting. 
    Editing SYS$MANAGER:STARTNET.COM is not a good idea since it may prevent 
    future corrections from being applied to that file during future system 
    software upgrades or the edits could simply be wiped out if the file is 
    replaced in some future upgrade.  (Further discussion of this topic belongs 
    in the VMSNOTES conference on VAXWRK, but read the previous discussion 
    there first.)

	It would probably be a very good idea if someone with authority to 
    speak for VMS/DECNET engineering followed up on the newsgroup posting.

>	It would probably be a very good idea if someone with authority to 
>    speak for VMS/DECNET engineering followed up on the newsgroup posting.

I suppose almost anyone could point out that the issue is addressed formally
by DEC on page 8-69ff of the VMS V5.0 Release Notes.

/john

re: the Internet virus...

My understanding is that the systems were locked, but the lock was
easily picked/forced.  (Sort of like car door locks and coat hangers.)

re: the Span virus:

Not all customers have V5, not all of them read the manuals or understand
the implications.  What struck me from the posting was that the existing
manuals seem to cover the problem, but the customers were still leaving
the systems insufficiently protected.  I suspect that it would take about
3 months to read the entire document set from start to finish.  Has anyone
actually done this?

Martin.

RE:  Note 655.62 by BOLT::MINOW 

>                                       I suspect that it would take about
>3 months to read the entire document set from start to finish.  Has anyone
>actually done this?
        
        And even if they read the whole thing, how long would it take
        to assimilate the knowledge to the point where you understood
        it all well enough to know what needed to be done?  In spite
        of our best intentions, VMS is a marvelously complex software
        system, and when you add DECnet to it, the complexity increases
        by perhaps an order of magnitude (depending on the number base
        you pick -- I'm thinking of base 1.5 or 2).
        
        Tom

Re .62:

I read in some conference (HACKERS?) that some people's solution to professional
obsolescence is to read the whole doc set every time it comes out.  A number of
conference members endorsed the idea, wherever it was I read it.
				/AHM

    In light of a worm's infestation of the EASYNET this past weekend
    (1-13-89---1-15-89) that tried to guess account passwords by using
    the account name as the password: 
    
    this worm inside DEC's EASYNET is a virtual carbon copy of the worm
    from NASA's SPAN network. If I wanted to be a hacker, but did not
    have the cranial capacity to do so (lack of technical knowlege),
    the worm that is posted in note 655.57 would be a good starting
    point for ideas. 
    
    For the good of the company, I feel that this note should be revised
    to remove the DCL command procedure coding. It is too easy to play
    around with. As a result of actions such as the EASYNET worm, I
    feel that our network's freedom may be in jeopardy. I do not want
    to see our tool of knowlege and information become restricted. 
    
    Please revise note 655.57 ASAP.
    Thank you. 
    Mike Taylor, INDEC Field Service, Salem, NH.

    Re: -1
    
    At 11am this morning the worm was STILL attacking nodes....  so
    its not JUST this past weekend....
    
    I will talk to the other moderators about setting .57 hidden,
    I'm not sure hiding it would accomplish all that much since its
    posted elsewhere on the net...
    
    Gale

    This weekend, a worm hit the Digital EASYNET.  The infection apparently
    caused no devastation, other than the global chaos resulting in the
    subsequent purging and "inoculation" of the entire network.  This
    chaos was, of course, non-trivial.  Our cluster was down a full day,
    which resulted in, among other things, an untold number of Managers
    (including me) who had no mail to read (:>{) ).  I notice that some
    clusters are still down. 
    
    The reason that I bring it up here, is that the worm (called: JIG)
    bares an uncanny resemblance to the worm published here in 655.57. In
    fact, I think it's reasonable to assume that the perpetrator learned
    the worm's "gimmick" in this conference.  Whereas the original SPAN
    worm, was content to display an annoying (albeit seasonal) message, the
    JIG instigator modified it to look for account names with matching
    passwords, and to mail notification of any matches to 60726::JONES. 
    
    The JIG worm was detected due, in my judgment, to sloppiness on
    the part of the "worm-er".  (Also read:  it has bugs in it.)
    
    Good things come out of bad:  Easynet should hereafter be immune
    to this worm strain.  (Too bad, system managers either don't read
    this conference, or choose to ignore security oriented advice.)
    Nevertheless, I would hate to consider the money (productivity loss,
    etc.) that this piracy caused.
    
    I don't know if 60726::JONES is a real person or not, but I, for
    one, hope he or she is identified and dealt with (also read: fired).
    
    L.

        Re: .67
        
>    I don't know if 60726::JONES is a real person or not, but I, for
>    one, hope he or she is identified and dealt with (also read: fired).
        
        So, you want someone fired because their account was used as a
        collection point for data from the worm.  Did you ever consider
        that the `owner' of the account may have nothing to do with the
        worm?  The account may have been created for M. Jones, but
        without M. Jones being aware that it was created (this has
        happened to me several times). 
        
        I assume you mean that you want the perpetrator, if a Digital
        employee, fired.  That's not unreasonable, but don't start
        firing anyone before you find out who is guilty.  [If I started
        a worm, I certainly wouldn't it to my own account.] 
        
        					B.J.

  Is there much point in setting note 655.57 hidden AFTER the easynet has been
  infected by the latest worm? Isn't it a bit late ??

  Why don't we all read about it, then we can attack it quicker should a 
  similar one arise in the future.

	Craig.

This is a resubmission of 655.57 with the actual code censored as,
apparently, there is at least one Dec employee who can't be trusted
with source code to a virus.

As noted in the posting from Nasa, good system management would prevent
this family of viruses from spreading.

Martin.

          <<< HUMAN::DISK$HUMAN_WRKD:[NOTES$LIBRARY]DIGITAL.NOTE;1 >>>
                          -< The DEC way of working >-
================================================================================
Note 655.57  Secure networks, viruses, and the way we work at Digital   57 of 67
BOLT::MINOW                                         715 lines   4-JAN-1989 16:16
               -< Benign worm targets VMS sites on SPAN network >-
--------------------------------------------------------------------------------

The attached -- very long -- message was distributed on the Internet
Virus discussion list.  It describes another worm program that
(benignly) attacked VMS systems attached to the NASA SPAN network.

(Note that these messages originated outside of Dec and, probably, have
been seen by several thousand system people already.)

What might be most interesting here for DIGITAL.NOTE readers is the way in
which information about the worm was distributed throughout the network.

Martin.

From:	THUNDR::DECWRL::"virus-l%SPOT.CC.LEHIGH.EDU@IBM1.CC.Lehigh.Edu"
	"Kenneth van Wyk  4-Jan-89 1421 EST"  4-JAN-1989 15:00
To:	Martin Minow <thundr::minow>
Subj:	     volume 1 issue 59b

 
VIRUS-L Digest             Thursday, 29 Dec 1988        Volume 1 : Issue 59b
 
Today's Topics:
DECnet HI.COM Christmas Worm
 
---------------------------------------------------------------------------
 
Subject: DECnet HI.COM Christmas Worm
Date: Mon, 26 Dec 88 08:19:06 -0800
From: Steve Goldstein <goldstei@nsipo.nasa.gov>
 
 
Greetings, this is my first posting to this mailing list, and I trust
that I do not bore you with info that you've already seen many times
over this past week.  These are a collection of msgs about a DECnet
worm which was launched just before Christmas to produce a greeting
from Father Christmas on SPAN nodes, HEPnet nodes, etc.
 
The msgs are forwarded for your information, mainly.  I suspect that
all node managers (sysadmins) will have secured their VMS machines
prior to receipt of this information.
 
Let's hope the New Year is not marked by new greetings borne by lower
"life" forms!
 
Steve Goldstein
goldstein@nsipo.arc.nasa.go
 
- ------- Forwarded Messages
 
Return-Path: medin@nsipo.nasa.go
Received: Thu, 22 Dec 88 15:56:24 PST from cincsac.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 15:55:45 PST from localhost.arc.nasa.gov by
 cincsac.arc.nasa.gov (5.59/1.5T)
Message-Id: <8812222355.AA07048@cincsac.arc.nasa.gov>
To: nsn-tech@cincsac.arc.nasa.go
Cc: goldstei@cincsac.arc.nasa.go
Subject: DECNET worm report
Date: Thu, 22 Dec 88 15:55:44 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
 
 
Folks, there is a worm running around SPAN at this time that
causes a procedure to be run that will try and send a Christmas
card to users on that system on Christmas Eve.
 
The worm can only propagate if task 0 is enabled, and default decnet
is present and has the password as decnet.  This configuration
is a bad idea in any case, but it allows this worm to infect
your system.
 
You can tell if it's on your system because the process name is
changed to MAIL_170DC and there is a HI.COM file in the default decnet
account.  Disabling task 0 will prevent infection.
 
More details later.  Please pass this information around and make
sure all systems at your site have the task 0 capability removed
in accordance with SPAN security guidelines.
 
Kudos to Brian Love at GSFC/CSDF for alerting us to the problem.  FYI,
it looks like the worm is sending a message to a node in Switzerland.
 
A copy of the command procedure is attached.  Feel free to call us
at NSIPO at Ames Research Center at (415) 694-6440 for further information.
 
Note, this doesn't appear to be a serious problem, but all system
managers should make sure their systems are secured.
 
                    Thanks,
                      Milo Medin
 
 
 
 
(Message inbox:5167)
Return-Path: 6173::system@sat.span.nasa.go
Received: Thu, 22 Dec 88 15:32:55 PST from gemini.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 15:32:41 PST by gemini.arc.nasa.gov (5.59/1.2)
Date: Thu, 22 Dec 88 15:32:41 PST
Message-Id: <8812222332.AA09707@gemini.arc.nasa.gov>
From: 6173::system@sat.span.nasa.gov (CSDR System Management, NASA/GSFC
 B7-R188A, (301) 286-3819)
To: medin@sat.span.nasa.go
Subject: Copy of Hi.Com - More information to come in separate file.
**
** Deleted
** 
- ------- Message 2
 
Return-Path: medin@nsipo.nasa.go
Received: Thu, 22 Dec 88 16:32:57 PST from cincsac.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 16:32:18 PST from localhost.arc.nasa.gov by
 cincsac.arc.nasa.gov (5.59/1.5T)
Message-Id: <8812230032.AA07140@cincsac.arc.nasa.gov>
Date: Thu, 22 Dec 88 16:32:14 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
Subject: DECNET worm report - correction
Apparently-To: <goldstei@nsipo.nasa.gov>
 
- - ------- Blind-Carbon-Copy
 
To: nsn-tech
Subject: DECNET worm report - correction
Date: Thu, 22 Dec 88 16:32:14 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin>
 
 
Oh, and a correction to my previous note, due to a garbled message,
I credited the wrong person at GSFC.  Kudos really go to Brian Lev,
not Brian Love.  Just wanted to set the record straight.  Sorry about
that Brian...
 
                    Thanks,
                      Milo
 
- - ------- End of Blind-Carbon-Copy
 
- ------- Message 3
 
Return-Path: pmbs@STSCI.EDU
Received: Fri, 23 Dec 88 13:16:21 PST from QUIPUS.STSCI.EDU by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Fri, 23 Dec 88 15:57:28 EST by quipus.stsci.edu.STSCI.EDU (5.59)
Date: Fri, 23 Dec 88 15:57:28 EST
From: (Peter Shames) <pmbs@STSCI.EDU>
Message-Id: <8812232057.AA04573@STSCI.EDU>
To: astro@stsci.edu
Subject: SPAN breakin attempts - a peculiar Merry Xmas greeting
Cc: broder@dftnic.gsfc.nasa.gov, gallagher@sam.span.nasa.gov,
        gallop@sacho.jpl.nasa.gov, goldstein@nsipo.nasa.gov,
        green@nssdca.gsfc.nasa.gov, jaw@sesun.jpl.nasa.gov,
        medin@nsipo.nasa.gov, milkey@scivax, schreier@scivax,
        torben@dorsai.ics.hawaii.edu, villasenor@ames.arc.nasa.go
 
Folks,
    The attached note describes a number of breakin attempts that
took place last night at STScI.  Many of you may also have been the
subject of this latest attack, some of your systems may have been broken
into.  The effects are of *this* attack are quite benign, but that, as
far as I can tell, was just luck.
 
    While I do not wish to dampen anyone's holiday revels, the
message in this latest attempt is clear and the implications troublesome.
 
    In spite of all this, I would like to wish you all a Very Merry
Holiday season, and a Happy New Year.
 
                        Peter
 
- - ---------------------------------------------------------------------------
 
TWIMC -
    Starting at roughly 1630 on 22 Dec 1988 VAX systems at the STScI
experienced several breakin attempts over the SPAN network.  The symptoms
were a series of login attempts on the accounts DECNET and NETFAL.  Over
the next couple of hours the number of attempts increased significantly,
though none were successsful.  One peculiar observation was that only one
of our system was initially attacked, and it was attacked repeatedly, from
an ever widening set of other hosts.
 
    A copy of the .COM file that was used for this attacked was
captured by one of the sites that was broken into, and it turned out to be
a rather simple script that selected a area/host number based on a
permutation of the date and time and then attempted to break into that
host on the two accounts indicated above.  It only tried a couple of
obvious passwords and then gave up with that host if not successful.
If successful it would replicate itself and then proceed from there.
The multiple attacks on the one host were due to the time zone rolling
around as the attacks spread westward and that one system having a number
that the algorithm generated often.
 
    Though the modus operandi of this attack was relatively benign,
that fact that it occurred at all is to be deplored.  The time that is
wasted in tracking down such pranks is significant, as is the general
disruption that is caused.  At the same time, the attacker could just as
easily have set up a program to delete files or do other mischief and
such an attack would have caused real havoc.
 
    This attack, coming via the SPAN DECnet network, just serves to
underscore the fact that wide area network connections, via whatever set of
protocols, to whatever operating systems, do offer targets to bored,
mischievious, or possibly malicious individuals.  Following, as it does,
on the heels of the Internet Virus of 3 November 1988, this serves
notice to all computer site managers that any system that has wide-area
network connections is potentially vulnerable.
 
    However, the benefits of having adequate wide-area networks are
too great for such actions to stop us from using them.  This kind of act
should serve as a timely warning that we all had best review our own
site and host security to identify and eliminate any latent opportunities
for future breakins.  At the very least all of the security holes employed
by these latest breakins should be eliminated immediately.  None of our
open science research sites wants to have to provide the sort of high
level security appropriate to a military installation, so we must all act
to preserve the integrity of the open research environments that we so value.
 
    Passing security related information in the open is not an especially
good idea, but some means of disseminating such information must be provided.
There is a SPAN site security guide that should be consulted and I believe
that a similar guide is being developed for the Internet community.  Perhaps
a meeting of astronomy site coordinators and system managers, convened in
conjunction with an AAS WGAS meeting or even separately, would be appropriate.
Comments or suggestions from all concerned would be appreciated.
 
                        Peter Shames
 
 
- ------- Message 4
 
Return-Path: tcp-ip-RELAY@SRI-NIC.arpa
Received: Sat, 24 Dec 88 20:37:27 PST from MITRE.ARPA by nsipo.arc.nasa.go
(5.59/1.5)
Organization: The MITRE Corp., Washington, D.C.
Received: from ron.rutgers.edu by SRI-NIC.ARPA with TCP; Fri, 23 Dec 88 12:57:48
 PST
Received: by ron.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
    id AA02489; Fri, 23 Dec 88 15:57:30 EST
Date: Fri, 23 Dec 88 15:57:30 EST
From: ron@hardees.rutgers.edu
Message-Id: <8812232057.AA02489@ron.rutgers.edu>
To: tcp-ip@sri-nic.arpa
Subject: DECNET Virus (sorry)
 
 
I got an anonymous tip about a DECNet virus.  Milo Medin provided me with
the details.  The virus exploits a well known feature in DECnet which involves
sites that leave TASK 0 running (this is the way DEC ships it).  The virus
sends a HI.COM file to your default decnet directory and then sends a command
to task 0 to invoke it.  To close the hole, you need to tell NCP
to "CLEAR OBJECT TASK ALL" in your start up files as DECNET always starts
this process.  If you were infected you will find HI.COM in your default
decnet directory and a process running called something like MAIL_178DZ.
 
You should delete the com file and kill off the process if you find them.
 
I don't vouch for the accuracy of the above, I am neither a DECNET nor a
VMS lover.
 
- - -Ron
 
I apologize for all those who are sane enough to run TCP-IP rather than DECNET
for having to see this, but it seemed like the most rapid distribution system
I could find.
 
 
- ------- Message 5
 
Received: Sun, 25 Dec 88 01:48:03 PST from ames.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Sun, 25 Dec 88 01:36:34 PST from SRI-NIC.ARPA by ames.arc.nasa.go
(5.59/1.2)
Date: Fri, 23 Dec 88 15:43:52 PST
From: DDN Reference <NIC@SRI-NIC.ARPA>
Subject: DDN MGT Bulletin # 50: Hi.COM DECnet worm
To: ;@MGT
Cc: dcab600@ddn1.arpa, dcab602-all@ddn1.arpa, cert@SEI.CMU.EDU,
        nic@SRI-NIC.ARPA
Message-Id: <12456817800.29.NIC@SRI-NIC.ARPA>
 
**********************************************************************
DDN MGT Bulletin 50              DCA DDN Defense Communications System
23 Dec 88                        Published by: DDN Network Info Center
                                    (NIC@SRI-NIC.ARPA)  (800) 235-3155
 
 
                        DEFENSE  DATA  NETWORK
 
                         MANAGEMENT  BULLETIN
 
The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************
 
SUBJECT:   Worm (Benign)
 
APPLICABLE OPERATING SYSTEM: DEC VMS
 
PROPAGATION: Propagates via DECNET protocols, not TCP/IP protocols
 
STATUS: Fix is enclosed
 
VALIDATION:  The fix has been forwarded to the CERT for validation, but
validation has not been completed.  But in order to provide timely
information to our subcribers, this fix is being made available "as
is".  It was provided by a host administrator on the NASA SPAN/DOE
HEPNET network.  We recommend that you contact your vendor and refer
to the vendor documentation listed below before attempting to implement the
fix.
 
 
PROBLEM: On Friday, 23 December, Gerard K. Newman of the San Diego
Supercomputer Center reported a Christmas Eve computer worm (not a
virus) called "HI.COM".  This worm appears to be a benign Christmas
greeting from "Father Christmas".
 
ESSENTIAL CONSIDERATIONS: The recent Internet Virus has sensitized the
telecommunications community to the potential threat of worms and
viruses.  However, "HI.COM" appears to be a prank and nothing more:
 
      (A) It only affects VMS machines connected to DECNET.
 
      (B) It does not use TCP/IP, thus it cannot "infect" the Internet
          (or MILNET/ARPANET).
 
      (C) It does no harm (all it does is send a "stop computing and go
          home" message after midnight on Christmas Eve).
 
      (D) It has safeguards against running multiple copies of itself on
          the same machine.
 
      (E) It will terminate itself after completing its mission (at 00:30
          on the 24th).
 
SYMPTOMS OF INFECTION: Some steps to take to determine if your system has
been infected are:
 
      (A) Check your accounting files and NETSERVER.LOGs in your default
          DECnet accounts for a file called HI.COM.
 
      (B) Check your processes for one named MAIL_178DC.
 
A FIX:
 
There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network.  The worm targets VMS machines, and
can only be propagated via DECnet.
 
The worm itself appears to be benign, in that it does not destroy files
or compromise the system.  It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988.  It
does have a hook in it to monitor it's progress;  it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.
 
The worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users who
don't have a specific login ID for a machine to have some degree of
anonymous access.  It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
copy.
 
There are several steps which you can take to protect yourself from this
kind of attack.  The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether.  This can be done with
the following commands from the SYSTEM or other suitably privileged account:
 
    $ Run SYS$SYSTEM:NCP
    Purge Executor Nonprivileged User Account Password
    Clear Executor Nonprivileged User Account Password
    ^Z
 
This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the "Guide to VMS System Security",
see below).
 
You can take less restrictive steps to protect your machine while still
maintaining some degree of default access.  If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):
 
    $ Run SYS$SYSTEM:NCP
    Clear Object Task All
    ^Z
 
You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line
 
    CLEAR OBJECT TASK ALL
 
AFTER the line which says
 
    SET KNOWN OBJECTS ALL
 
This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database.  These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine;  but they
will prevent it from being executed.  To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):
 
    $ Set Default your-default-decnet-directory
    $ Create HI.COM
    $ Stop/ID=0
    ^Z
    $ Set File/Owner=[1,4]-
    /Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM
 
This prevents anyone from copying a file called "HI.COM" into your default
DECnet account;  however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account.  This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account.  The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):
 
 
    $ Set Default SYS$SYTEM
    $ Run AUTHORIZE
    Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
    /Password=randomstring/Device=disk-device/Directory=[some-directory]-
    /Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
    /NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
    /LGICMD=SYS$SYSTEM:FALLOG.COM
    ^Z
    $ Run NCP
    Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
    Password same-random-string
    Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
    Password same-random-string
    ^Z
    $ Create FALLOG.COM
    $ V := 'F$Verify(0)
    $ Write SYS$OUTPUT ""
    $ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
    $ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
    $ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
    $ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
    $ Write SYS$OUTPUT ""
    ^Z
 
This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa.  The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.
 
The FAL program can supply additional logging information;  contact your
DIGITAL software support person for further details.
 
Further steps can be taken to restrict access to your system.  These
steps are discussed in detail in the "Guide to VMS System Security", DEC
order number AA-LA40A-TE, dated April 1988.  See in particular chapter 7,
entitled "Security for a DECnet Node".
 
For general information about this patch call the CERT or the Network
Information Center at (800) 235-3155.
 
This represents the best information available at this time to fix this
problem.
 
 
- - -------
 
 
- - --- End of forwarded message from DDN Reference <NIC@SRI-NIC.ARPA>
 
 
- ------- Message 6
 
Return-Path: tcp-ip-RELAY@SRI-NIC.arpa
Received: Mon, 26 Dec 88 00:07:50 PST from MITRE.ARPA by nsipo.arc.nasa.go
(5.59/1.5)
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun, 25 Dec 88
 23:07:38 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.33)
    id AA02165; Sun, 25 Dec 88 22:41:55 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
    (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 26 Dec 88 06:39:55 GMT
From: brian@ucsd.edu  (Brian Kantor)
Organization: The Avant-Garde of the Now, Ltd.
Subject: Re: DECNET Virus (sorry)
Message-Id: <1339@ucsd.EDU>
References: <8812232057.AA02489@ron.rutgers.edu>
Sender: tcp-ip-relay@sri-nic.arpa
To: tcp-ip@sri-nic.arpa
 
I received the following message last Friday; I mailed it off to
the "phage" security list and it bounced because Purdue's mailer is
broken, so I'll post it here.  I hesitated to do this at first, since
it's not directly relevant and I sure didn't want to panic people into
wildly shutting down bridges and gateways again.
 
SPAN (Space Physics Analysis Network??) is a DECNet network, so it
lacks direct relevance to the TCP/IP list, but probably this is of
at least passing interest.
- - ---
Date:    Fri, 23 Dec 88 02:53:13 GMT
From: gkn@Sds.Sdsc.Edu (Gerard K. Newman)
Subject: SPAN WORM ALERT
 
Ladies and gentleman,
 
Someone has loosed a worm on SPAN at this very moment.  Check your accounting
files and NETSERVER.LOGs in your default DECnet accounts.  You'll find evidence
of someone creating a file (HI.COM, which I am in the process of fetching from
the deleted blocks of one of them) which propagates itself around the network.
 
It has hit all of the VMS machines here at SDSC today, and simply appears to
crawl around and send mail to 25097::PHISOLIDE (node 25.79, for which I do not
have a name in my DECnet database).
 
It will take me a few more minutes to cobble together a program to dredge up
the blocks of the command file (one of the first things it does is to delete
itself ... it also sets it's process name to MAIL_178DC, so look around for
those, too).  When I have it I will forward the text.
 
An adequate defense against the problem is:
 
(from the SYSTEM or other suitably privileged account):
 
    $ Set Default your-default-decnet-area
    $ Create HI.COM
    $ Stop/ID=0
    ^Z
    $ Set File/Owner=[1,4]/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM
 
This information should receive the widest possible distribution.
 
I will forward a copy of the command file in a few minutes.
 
Please give me a call (# below) if you need more information.
 
gkn
- - ----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:      SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:      Gerard K. Newman
      San Diego Supercomputer Center
      P.O. Box 85608
      San Diego, CA 92138-5608
Phone:      619.534.5076
 
- ------- End of Forwarded Messages
 
------------------------------
 
End of VIRUS-L Digest
*********************

Martin, I don't think you should feel at all guilty about having posted
the virus here; it was readily available in many other places.

/john

    Re: .68
    
    	Yes, of course I agree.  By the way, I question whether or not
    the responsible individual was smart enough to hide their own identity.
    In the first place, there "cleverness" (What the Globe might term
    "genius" or "whiz kid") was a non-original idea, copied from a public
    forum.  Secondly, (as I said) it was sloppily implemented - it didn't
    do what it was (apparently) supposed to do.
    
    Re: .69
    
    	I agree.  It's silly to hide it now.
      
    
    L.

    
    Writing a worm is probably a standard exercise in DECnet class.
    It's dead easy.
    Anybody really wanting to know the "mean" worms has access to 
    plenty of examples. 

    Your's systems were down ? But not ours .
    For some unknown reason ( developing paranoia ?) I did chase up 
    some system managers around me 10 days ago....

    				[... so they were after me anyway ???]

        There were *at least* two worms loosed on the network; there may
        have been more.
        
        Yes, the worms appear to have been based on the HI.COM procedure
        that infested the NASA SPAN network.  It's no more likely that the
        person who loosed the worm on the network read it here than that
        they are on the Internet Virus discussion list mailing and got it
        directly, or got it through some other mechanism.
        
        Hiding information about this worm, including the command files
        that implement it, doesn't make anyone's system secure.  It just
        leads to a false sense of security. 
        
        Any system that implemented the security recommendations in the
        note posted here was safe from penetration.  The "VAXINE" that was
        inserted on many systems in response to these worms DID NOT make
        the systems secure, in general, against penetration by future
        worms that use the same techniques.  It just breaks the particular
        (not very clever) implementation used in this instance, and does
        it in a way that *CAN* lead to a false sense of security (as
        evidenced by earlier replies to this topic asserting that systems
        have been "vaccinated" against the worm). 
        
        If your system was "penetrated", and your username was not the
        same as your password, then when you logged in after the "attack",
        VMS told you that someone had made on or more attempts to log in
        to your account, and had failed.  (Each penetration led to another
        failed attempt.)  If your username was the same as your password,
        then the "cracker" knows it now, and you should change it.  (You
        should NOT have the same password as your username ANYWAY, right?) 
        
        Some system managers, even on systems that were not penetrated,
        have chosen to invalidate ALL passwords and require EVERYONE to
        change them, even though there is no need to do so. 
        
        For the sake of those who don't understand what happened, the worm
        made use of two default mechanisms in the VMS implementation of
        DECnet.  One is the ability to transfer files across the network
        into a default location using a default account, and the other is
        the ability to invoke a task to execute a command procedure on a
        remote node.  These are both well-understood, and are there for
        good reasons.  
        
        Once the command procedure was copied onto a node and invoked
        there, it copied itself into memory and deleted itself from disk
        (cleaning up the evidence somewhat).  Then it read a file that
        lists the usernames on the system (or used the SHOW SYSTEM command
        to get similar information for all active processes), and tested
        each user account to see whether the password was the same as the
        user name.  If so, it mailed the user name to an account on a
        remote node.  (It's very likely that the account in question was
        NOT the account of the perpetrator; rather, it is probably an
        unused account that had the same user name and password, with MAIL
        set up to forward all incoming messages to yet another account,
        and so on.  This can be VERY hard to trace.)  Once it had done
        this scan, it went into a mode where it attempted to propogate
        itself to other nodes on the network, using the same mechanism. 
        
        Protection against this worm is relatively straightforward. One
        very reasonable thing to do (which is suggested in the NIC memo)
        is to change the FAL object to use a different UIC than the
        default DECnet account, and set up that account so that the
        default directory is NOT the same as that used for default DECnet
        access.  (It can be helpful to set it up so that log files go to a
        different account than the one that files copied onto the system
        will occupy, or even set it up so that, by default, it's not
        possible to simply copy files onto the system.)  The procedures
        indicated in the memo to do this are essentially correct, but if
        you are running SECUREPACK, you want to make sure that you still
        invoke the SECUREPACK network login procedure. 
        
        The second thing that's reasonable to do is to disable the TASK
        object for use by the default DECnet account.  The NIC memo
        suggests ways to disable it altogether, but this is probably a
        mistake.  It suffices to establish a username and password for it
        that are invalid.  This still allows PROXY access, as well as
        access by specifying a valid control string (but make sure that
        the password for the DECNET account isn't DECNET!).  Since the
        TASK object has many *legitimate* uses, especially in a DECwindows
        environment with distributed applications, it's a mistake to break
        it for the valid uses. 
        
        The security mechanisms to avoid this sort of problem are well
        understood, and this particular "loophole" in the default setup of
        VMS DECnet networking was known long before this "worm" showed
        many of us that we hadn't done an adequate job of securing our
        systems. 
        
        I fear that the "corporate" response will be to over-react, write
        many poorly stated policies, and fail to address the real security
        problem, which is that many people don't understand security
        issues (both human and technical) well enough to implement policies. 
        
        And yes, perhaps the technical aspects belong in some other more
        relevant conference, but many of you would not go read it. 
        
        Tom

I was one of those folks who tried to report the virus Saturday morning.
But who to tell?

I checked my phone book under the title of "corporate security" hoping to
find an appropriate listing like "Network Security Emergency Number" "Or
call this number in case of viral attack on a weekend". Found nothing, so I
tried calling all Corporate security numbers realizing that I would not get
anyone on a Saturday. 

No luck, so I tried calling my own security folks down in the BXB1 lobby. I
knew they wouldn't know what I was talking about but I was hoping that they
might have a procedure for contacting the appropriate people on the
weekend. Total lack of understanding -- they gave me the home number of a
cluster manager in Littleton.  This was a corporate wide problem: why
would I want to speak to an individual cluster manager?

Not knowing at the time who I was calling, I called the cluster manager.
When I found out who he was I was quite upset. Fortunately, this cluster
manager was a pretty bright guy and gave me the names of some folks who
work at VRO. So I tried to call VRO security to contact them at home. No
luck, VRO security is not staffed during the weekend so I had to call Mill
Security. 

Mill security can't even find the home number for one of the individuals.
However, I get lucky -- one of the security folks there has an idea of who
to call even though there is nothing written down laying out a procedure
for him. I finally get in touch with some corporate security person.
Considering that only one other group (from CXO) had contacted him so far,
I felt justified in tracking him down to report it also. 

It took me 1.5 hours to finally report this to someone who could do
something.


From this experience, I think DEC needs to do a few things in addition
to dealing with the VMS system issues:

	- Put an entry in the internal phonebook for reporting viruses.
          Make it easy to find. Have some sort of fallback number for
          weekends.

        - Establish a procedure for security to follow when someone
          reports a virus. Make certain that security knows who else
          to contact in the corporation to report it -- especially during
          weekends.

    We got both worm models.  DUMP reveals that one forwards a MAIL
    message to a system in Australia, the other to a system in New Jersey.
    
    changing FAL.EXE's UIC to a non-DECnet account area is a point well
    taken.
    
    karl in Arizona

    For those interested, there is a complete (and rather fascinating)
    discussion of the technical details regarding the two (at least) worms,
    including what is presently known regarding the mail-back nodes, the
    (dramatic) unfolding of the counter attack, etc. in
    HUMAN::SECURITY_INFORMATION  (topic 276).
    
    L.
    
     

    re .57 and the code it posted:
    
    I haven't read all the scoop yet and I don't know whether the identity
    of the perpetrator(s) is known, but I wouldn't be so quick to assume
    that a Digital employee extracted HI.COM from .57 and then let it
    loose after modifying it.  Implicitly we trust fellow employees
    to not do this sort of thing.
    
    It's entirely possible for an intruder to have gotten HI.COM from
    other sources and then infected EASYnet after breaking in.
    
  --Simon
    

    Re: .74
    
    O.K...since this is the conference on "The way we work at Digital",
    let's address those issues with regard to these security problems.
    
    It seems to me that we, as a corporation, would benefit with some
    kind of comprehensive training program for facilities system managers
    on security.
    
    Perhaps corporate could distribute a periodical to system managers
    (electronically?) about current worms, viruses, etc. and how to
    cope with them.
    
    Doug

    
    re. 75 .
    
    Well, well, I see a customer for a newly designed security consulting
    service .-))
    
    Here comes a risk assesment sheet also :
    
Network security risk sheet.			
-----------------------------------------------------------------------------	
Risk ID : 001

		Risk 		
		H
		^				Type :	( availability ) *
		| *					( confidentiality )*?
		|					( integrity )
Impact	   <----*----> H		
		|
		|

------------------------------------------------------------------------------
Risk description :

	Security alarms/incident information gets lost.






Risk's likelihood	:


	high, no widly know security desk





Impact	assessment :


	high, for obvious reasons






-------------------------------------------------------------------------------
How to detect it :


	read note .75


How to prevent it :


	Esatblish a central network security desk manned 24h/7d


Possible next step if risk is compromised ( forward pointer):


	not applicable


Possible previous step if risk is compromised ( backward pointer, optional):

	
	not applicable
Customer : Digital 	Date: Jan 89			Author	: WS
    

I reposted a censored version of 655.57 at the request of one of the
moderators, who was reacting to a request posted as a reply in this note.

The moderators are, of course, welcome to un-hide 655.57 and delete
the censored version.

Martin.

    Being a lowly user, not a cluster manager or other exalted being,
    I have a couple of questions:
    
    1) Would the proper use of SECUREPAK prevented the worm from "harming"
    the "securepak"ed system?
    
    2) If not, will the next release of SECUREPAK prevent such an attack?
    
    3) Are not all VMS systems connected to the EASYNET required by
    policy to use SECUREPAK?
    
    Protecting the systems from such attacks by modifying them, rather
    than using the head-in-the-sand approach (hide the worm) would seen
    to have several benefits:
    
    1) It would protect against this particular worm.
    
    2) It would protect against other worms of the same genus, either
    spawned from the now hidden worm as well as those that arose through
    independent creation.
    
    I was quite amazed to read the now hidden worm text and discover
    that such a system attack could be performed just using DCL.
    
    Maybe appalled would be better than amazed.

    /s/ Jim Williams

>    1) Would the proper use of SECUREPAK prevented the worm from "harming"
>    the "securepak"ed system?
    
    Yes, I believe it would. The files would still have been copied to the
    system but would not have been able to be run.
    
>    3) Are not all VMS systems connected to the EASYNET required by
>    policy to use SECUREPAK?
    
    Yes, they are. Inforcing this is not easy though. Some people do
    install SECUREPAK but do not install all of the recomendations.
    
    			Alfred
    

    Re: .82
    
    > I was quite amazed to read the now hidden worm text and discover
    > that such a system attack could be performed just using DCL.
    >
    > Maybe appalled would be better than amazed.
    
    Why were you appalled?  If we are going to make computers usable
    by everyone, it must be easy to do complex things.  The richness
    of DCL is one of the reasons that productivity is greater and
    development costs are lower on a VMS system than on most other vendors
    equipment.
    
    Bob

>    1) Would the proper use of SECUREPAK prevented the worm from "harming"
>    the "SECUREPAK"ed system?

	Maybe Yes, maybe No.  SECUREPAK is not a single process that is 
    applied to a system.  It has a number of options that can be used or not 
    used.  One of the SECUREPAK options would have deleted the TASK object that 
    is used by the worm to propagate itself.  Unfortunately, there are products 
    that need the TASK object to work properly.  As a result, it is one of the 
    less popular options.  Also, SECUREPAK can produce a lot of noise and waste
    a lot of the system manager's time.  As a result, it is often turned off
    after it was originally turned on.

Re Worms in General:

	Also of interest is the fact that this is not the first worm to get
    loose on the net internal to DEC.  I remember a rumor about one that was
    running around Europe two or three (or was it four?) years ago.  Worms are
    incredibly easy to write.  It is not particularly startling that we had
    a worm get loose at DEC.  What is absolutely amazing is the fact that we
    have not had many more infections than we have had.  It is a tribute to the
    quality of people at DEC that this kind of problem is so rare.

Re Management Reaction:

	There is already a problem with over-reaction.  Some sites are requiring
    that the File Access Listener (the thing that lets you do COPY node::...) be
    disable as well as the TASK object.  Another reaction has been to restrict
    distribution to the external (as in outside) electronic newsletter on 
    computer risks.  (This may have been a response to the publication of the
    source code for the HI worm or it may have been a result of comments in the
    newsletter by DEC employees, but it has made tracking known problems a bit
    more difficult.)

                                    
    I think that this worm is going to have a really big impact on "the
    way we work at Digital."  I've already heard of an instance where
    a cluster manager has decided to "shut down" DECNET from Friday
    pm to Monday am., and I'm pretty appalled at that.  Going back to
    earlier discussions in this topic, I think this has clarified for
    me why purely "malicious" behavior like this is dangerous  
    (even criminal): it has served to restrict *my* environment even
    though I follow the rules.
    
    If the cluster shutting down contains notesfiles that I read on the
    weekend because they're interesting and informative, I'm out of luck.
    If this cluster serves a support function and its users are located
    in the SPR, they're out of luck.  And more important, who says that
    worms only come out on weekends?
    
    This is an extreme example, but it does point out the potential
    for this worm to impact our lives.  So what do we do?
                                                                      
    I think that official policies often tend to be so clouded in Decspeak
    that nobody much wants to read them.  But is there some other
    effective way to make practical policy recommendations that are likely
    to reach all of us?   Should there be (are there?) security
    prerequisites that nodes have to meet before they can register their
    names and become fully functional network members?   Or is that
    too restrictive?   How do we go about effectively "policing" the
    network so that we can continue to enjoy the way we work at DEC?
    
    
    

>Another reaction has been to restrict distribution to the external (as in
>outside) electronic newsletter on computer risks.

Are you sure about this?  Are you saying that if someone at DEC had a
subscription to RISKS-Forum that the subscription has been cancelled?

/john

    
    Example of a worm that mails system manager "your systems are susceptible
    to worms" should be in DECnet/VAX manual.
    We should have such a worms trying out Easynet all the time.
    More worms !!! 
    The philosophy behind default settings is ease of use, maybe balance
    has changed, maybe worms shouldn't propagate due to default settings.
    Over reaction to what happened damaged us more then the worm.
    Just type "mc ncp def/set object task num 0 user not%valid" and
    worms are DEAD.

    We should be grateful that this one was not malicious, set our
    objects correctly and forget this minor incident concerning a tiny
    minority of our systems.

Re: .88

The Risks-Digest used to be posted as daily entries in a notesfile. The
notesfile as well as VAXnotes seem to have disappeared from that node.

Sigh.

Lee

        RE: .88, .90 -- That has *nothing* to do with this "worm".
        The decision not to do the RISKS digest conference was made
        several weeks before this worm hit, and it was done because
        the person doing it could no longer justify the use of the
        resources.
        
        It's possible that the earlier note (which was unclear) meant
        that people will no longer be able to get the "comp.risks"
        USENET re-distribution, which would be unfortunate, as it has
        useful information about defeating or avoiding risks, or it
        may mean that because of some incident involving submission
        of "internal use only" information to the RISKS-Digest, that
        people will no longer be able to mail submissions through the
        gateway (but this seems almost impossible to enforce).
        
        I suspect that this is simply an unfounded rumor.  If someone
        (perhaps the author of the earlier note) would care to provide
        accurate information that can be independently confirmed, not
        speculation, it would be welcome.
        
        Tom

    I get the risks digest from the USENET and have noticed no
    interruption. The last one came the 18th, at 12:37.
    
    		-John Bishop

re: .89

>    We should have such a worms trying out Easynet all the time.
>    More worms !!! 

Yea, why not?  Maybe we should have a group dedicated to researching the
latest computer attacks and writing their own worms/viruses.  After all,
we are the most extensive users/testers of our own network.  Why not have
some creative software developers routinely try to break into Digital's
own systems?  Not because they're mischievous but because it's their
charter to do so.  Then maybe we could get a grip on stopping these
annoyances.

Phil

    
    Re: trying out worms on the Easynet all the time...
    
    You better plan on increasing the entire network bandwidth before
    this kind of thing is ever attempted. And then plan on wasting *LOTS*
    of CPU cycles. A much BETTER idea is to form a "subnet" of test
    machines, duplicate the Easynet environment, THEN try to "worm"
    your way to better knowledge/understanding.
    
    Actually, a process is already in place to do some minimal "checking"
    (not a worm or virus!!) on various systems throughout the Easynet.
    XSAFE is one tool used to verify protections on certain critical
    system files. A group at DIS (I think thats who) also does random
    testing of known objects, etc.
    
    In fact, one of our V5 test systems on the Easynet was tested for
    TASK 0 access and a red flag raised. So it sounds like someone out
    there is already checking up on systems. Last I knew they worked
    by DECnet area number and sometimes they even told you beforehand
    your systems were about to be tested.
    
    But my guess is they do not have the resources to keep up with the
    expansion of the Easynet. After all, there are a lot of nodes out
    there. And network bandwidth is a big constraint, as well as the
    fact that you should do testing during off hours, limiting the
    window of productivity.
    
    							Warren

Re .88:

>>Another reaction has been to restrict distribution to the external (as in
>>outside) electronic newsletter on computer risks.

>Are you sure about this?  Are you saying that if someone at DEC had a
>subscription to RISKS-Forum that the subscription has been canceled?

	As noted in a later note, this has to do with the NOTES file of the
    same name and was done before, not after, the worm got loose on EasyNet.
    The shut down did follow COMP.RISKS publishing the source code for HI.COM
    worm on the SPAN net and the inclusion in the newsletter of messages from 
    DEC employees that MIGHT have been better left out of a public discussion.  
    I do not have details about what was really behind the shutdown but when I
    asked I got some vague mumbling about security and pressure from 'high up'. 

	It may well be that SNDBOX was not the right place for the RISKS
    NOTES file, but the usual practice in cases like this is to put the file up
    for adoption for at least a couple days, if not a week or two, before
    killing it.

	It should be noted that the NOTES file represented a net saving to DEC.
    Without the NOTES file, everyone who is interested in the COMP.RISKS
    newsletter has to keep their own copy.  With the NOTES file, there is only
    one copy.  For the same number of interested persons, the total network 
    usage would be the same and the peak network usage would be worse.  Without
    the NOTES file, the newsletter is distributed when it arrives from USENET.  
    With the NOTES file, the information is distributed either when the reader 
    wants the information, or when some batch job comes to collect it.  

	I apologize for the poor way I presented the problem originally.  The
    information I have indicates that something strange, and in my opinion
    alarming, has happened with this particular issue.  Security is a very 
    important part of running a business, but it is also possible that security
    issues can get in the way of running a business.  Without security, the
    transfer of information between people is too unreliable to be useful.  Too
    much security can prevent the transfer of needed information.  Care has to
    be taken that neither extreme becomes dominant.  We have just had a major
    incident that has increased the awareness of our security deficiencies.  As
    a result, security will be tightened.  We have to be very careful that we
    do not go too far with this process.

        RE: .95 -- While I agree with you that there may be some savings
        to the corporation in maintaining a single archival copy of the
        RISKS digest, rather than many, I am unconvinced that there is any
        need to maintain an archival copy at all, or that the best way to
        do so is through Notes (rather than, say, using VTX to implement a
        RISKS-Digest infobase).  But that's a discussion better left to
        another forum, perhaps.  
        
        I can assure you, however, that the decision to discontinue the
        old RISKS conference had little to do with the appearance in the
        RISKS-Digest of information on the SPAN worm incident.  I am not
        at liberty to discuss the details.  
        
        I agree that it would be a mistake to over-react, as that would
        turn what may have been intended as a (poorly thought out) Friday
        the Thirteenth prank into a significant "denial of service"
        attack.  This can only happen if the management response is done
        in a way that compromises our ability to use the EASYnet to
        facilitate "the way we work at Digital".  
        
        Historically, Digital has been a relatively open company with
        regard to internal sharing of information, while taking reasonable
        (and sometimes inadequate) steps to limit the external disclosure
        of proprietary (business) information.  In my opinion, it would be
        a mistake to over-react to this incident and radically restrict
        the flow of information within the company, and the flow of useful
        information *into* the company through such mechanisms as the
        Internet gateway.  At the same time, there is a need for ethical
        behavior on the part of all employees in the use of the EASYnet
        and the gateways to other networks.
        
        The attached memo appeared in the RISKS-FORUM digest.  It is not
        the final word (since it's posted as a request for comments), but
        it certainly provides food for thought.  In my opinion, the ideas
        it presents about ethical use of the Internet apply just as well
        to ethical use of the EASYnet. 
        
        Tom
        
 
RISKS-LIST: RISKS-FORUM Digest  Sunday 15 January 1989   Volume 8 : Issue 8
 
 
Date:     Sun, 15 Jan 89 18:48:42 PST
From: cliff@Csa5.LBL.Gov (Cliff Stoll)
Subject:  Ethics of the Internet - Request for Comments
 
Network Working Group							IAB
Request for Comments: PPPP				 January 1989
 
				Ethics and the Internet
 
Status of this Memo
 
This memo is a statement of policy by the Internet Activities
Board concerning the proper use of the resources of the Internet.
 
Introduction
 
At great human and economic cost, resources drawn from the U.S. and government,
industry and the academic community have been assembled into a collection of
interconnected networks called the Internet.  Begun as a vehicle for
experimental network research in the mid-1970's, the Internet has become an
important national infrastructure supporting an increasingly widespread,
multi-disciplinary community of researchers ranging, inter alia, from computer
scientists and electrical engineers to mathematicians, physicists, medical
researchers, chemists, astronomers and space scientists.
 
As is true of other common infrastructure (e.g. roads, water reservoirs and
delivery systems, and the power generation and distribution network), there is
widespread dependence on the Internet by its users for the support of
day-to-day research activities.
 
The reliable operation of the Internet and the responsible use of its resources
is of common interest and concern for its users, operators and sponsors. Recent
events involving the hosts on the Internet and in similar network
infrastructures underscore the need to reiterate the professional
responsibility every Internet user bears to colleagues and to the sponsors of
the system. To the extent that the Internet resources are provided by the U.S.
Government, this responsibility becomes a Federal matter above and beyond
simple professional ethics.
 
IAB Statement of Policy
 
The Internet is a national facility whose utility is largely a consequence of
its wide availability and accessibility.  Irresponsible use of this critical
resource poses an enormous threat to its continued availability to the
technical community.
 
The U.S. Government sponsors of this system have a fiduciary responsibility to
the Legislature to allocate government resources wisely and effectively.
Justification for the support of this system suffers when highly disruptive
abuses occur.  Access to and use of the Internet is a privilege and should be
treated as such by all users of this system.
 
The IAB strongly endorses the view of the Division Advisory Panel of the
National Science Foundation Division of Network, Communications Research and
Infrastructure which, in paraphrase, characterized as unethical and
unacceptable any activity which purposely:
 
	(a) seeks to gain unauthorized access to the resources of the Internet
        (b) disrupts the intended use of the Internet
	(c) wastes resources (people, capacity, computer) through such actions 
	(d) destroys the integrity of computer-based information
or	(e) compromises the privacy of users
 
The Internet exists in the general research milieu. Portions of it continue to
be used to support research and experimentation on networking. Because
experimentation on the Internet has the potential to affect all of its
components and users, researchers have the responsibility to exercise great
caution in the conduct of their work. Negligence in the conduct of
Internet-wide experiments is both irresponsible and unacceptable.
 
The IAB plans to take whatever actions it can, in concert with Federal agencies
and other interested parties, to identify and to set up technical and
procedural mechanisms to make the Internet more resistant to disruption. Such
security, however, is extremely expensive and may be counterproductive if it
inhibits the free flow of information which makes the Internet so valuable. In
the final analysis, the health and well-being of the Internet is the
responsibility of its users who must, uniformly, guard against abuses which
disrupt the system and threaten its long-term viability.
 
------------------------------

Risks Forum is still available to DEC employees.

You can get it through its DEC redistribution from its Internet source by
sending mail to DECSRC::RISKS-REQUEST.

You can also get it from the DEC Usenet distribution by following the
instructions for getting Usenet stuff in the conference ROLL::USENET.

But it originates on the Internet, not the Usenet, so I would think that
the DECSRC::RISKS-REQUEST address would probably get you a copy a day earlier.

/john


P.S.:Conjecture: I suspect the SNDBOX archive was deleted to deal with a certain
specific person being denied access to Risks after he did something dumb, and
was in no way an attempt to keep the rest of DEC from reading this useful info.

Re .96:

>        RE: .95 -- While I agree with you that there may be some savings
>        to the corporation in maintaining a single archival copy of the
>        RISKS digest, rather than many, I am unconvinced that there is any
>        need to maintain an archival copy at all, or that the best way to
>        do so is through Notes (rather than, say, using VTX to implement a
>        RISKS-Digest infobase).  But that's a discussion better left to
>        another forum, perhaps.  

	I have had at least one instance since the RISKS notes file went away
	where I had a problem that was covered in RISKS.  It would have saved
	me some time if the NOTES file were still there.  On the other hand,
	there is a lot of stuff in RISKS that is delete-on-read as far relevance
	to me is concerned.

>        I can assure you, however, that the decision to discontinue the
>        old RISKS conference had little to do with the appearance in the
>        RISKS-Digest of information on the SPAN worm incident.  I am not
>        at liberty to discuss the details.  

	Thank you.  That information is reassuring in itself.

We seem to be witnessing the birth of an Urban legend.  As far as I know,
the source to HI.COM was never distributed by the Risks-Digest.  It was,
however, included in a long message rebroadcast from the VIRUS-L discussion
list that originates from Lehigh University on Bitnet.

I strongly recommend that all Dec professionals read Risks.

Martin.

        I concur with Martin that all DEC professionals should read the
        Risk-Digest, but would broaden that recommendation to include all
        employees, no matter what their role, and would even encourage you
        to print it out and give it to your friends who don't have access
        to electronic information dissemination. 
        
        Tom

	The point I wanted to make is that we will never get rid of
	attempts to start a worm and it would be mistake to try to , 
	would mean unacceptable restriction on the network use. 
	
	But, we should get rid of *worms* . 
	Worms should not , and probably already don't,
	 have a chance to survive in Easynet.

	Worms attempts should be simply seen then as a trivial accidents,
	like somebody touching a handle of a closed door.
	
	Once worms can't propagate, attempts to start one don't 
	cost much and what is more important, have tracable source 


		See you on Monday, after worm free weekend....
    

>	Worms should not , and probably already don't,
>	 have a chance to survive in Easynet.
    
    Great, an open challange to the hackers still around dumb enough to
    try it. :-) Actually should not is a good goal. I don't have enough
    in some unnamed groups to believe we've quite gotten there yet though.
    
    			Alfred

From the net.
 
VIRUS-L Digest            Wednesday, 25 Jan 1989        Volume 2 : Issue 25

------------------------------
 
Date: Wed, 25 Jan 89 14:40:34 est
From: ubu!luken@lehi3b15.csee.lehigh.edu
Subject: Friday the 13th worm at Digital Equipment Corp.
 
>From Digital News, January 23, 1989 issue (author Stephen Lawton):
 
"A late-night, Friday-the-13th worm that entered Digital Equipment
Corp.'s internal Easynet network in Maynard, Mass., earlier this month
bit off more than it could chew.  A systems manager spotted the
abnormal activity 'virtually as it entered' and was able to segregate
the infected system before the worm could spread, according to the
company.
 
Spokeswoman Nikki Richardson said the infected system was disconnected
immediately from the network while a vaccine program was developed and
installed.  The system was returned to the network before employees
arrived for work Monday morning, she said.
 
Unlike a virus, which replicates itself and destroys or modifies
data, a worm only replicates itself.
 
Digital would not disclose what type of system was involved, although
Richardson said she believes it was a VMS-based system, the
predominant system on the network."
 
Interesting...  It's nice to hear that DEC was able to stop it before
it caused any harm, I imagine that a congratulations is in order if
the report is accurate.
 
The scary part about the report, in my opinion, is the definition of
virus vs. worm; it's blatantly wrong.  In "Computer Viruses: Theory
and Experiments" (Computers & Security 6 (1987) p. 22-35), Fred Cohen
defined a virus as, "...a program that can 'infect' other programs by
modifying them to include a possibly evolved version of itself."
There's no mention of destroying or modifying data there.  In fact, in
his dissertation, Dr. Cohen even used an example of a virus that could
be worthwhile, a "compression virus" that would compress executable
files on disk in order to save disk space.
 
Ken
 

        There is a memo being circulate (by MAIL) that appears to have
        originated in Corporate Security.  (One copy I received had a mail
        header trail that led back to an alleged original source.) 
        
        Some people are sending along versions that have all the headers
        removed (why do people do this?).  One copy I received said 
        
MULTIPLE HEADERS DELETED.  RECEIVED THIS NOTE FROM A RELIABLE SOURCE THOUGH SO
THOUGHT I WOULD SEND IT ON IN CASE ITS A VALID WARNING....  
        
        Right!  Send it along, just in case!  Sigh...

        If you receive something that has the headers removed so you can
        no longer tell where it originated, don't assume that it is valid. 

        The gist of the memo is a warning that, come Valentine's Day,
        people might be sending around (via MAIL) programs that could be
        damaging to the recipients.  This is an amusing concept, and one
        that is apparently poorly understood by MANY people.  Of course,
        this can happen at any time, not just at Valentine's Day. 
        
        Here's what the message says:
        
Be advised that mail sent on Valentine's day may contain software
hazardous to Digital, your account, the Cluster etc.  So please, be careful
that you do not execute programs sent to you by people you do not know.
Please be alert to this type of activity and warn your friends of the
possibility of such activity. 

        People sometimes mail command procedures to others, together with
        imbedded instructions that tell the recipient to extract the mail
        message into a file and then invoke the file as a DCL command
        procedure. 
        
        A mail message, in and of itself, can do no damage.  It is benign.
        Even if it contains a program, it can do no damage to you unless
        you activate the program.  
        
        A healthy interest in self preservation suggests that you should
        NEVER trust anything you received in an unsolicited message to be
        as it claims, unless you can verify it.  This is ESPECIALLY true
        of DCL command procedures.  If you can't tell what the procedure
        does by reading it, DON'T INVOKE IT TO FIND OUT.  If you can tell
        that it will do damage, contact your site security manager as well
        as your system manager.  Don't just delete the message.  And don't
        forward it to your friends to see if they fall for the joke. 
        
        Nothing in the standard MAIL protocols used on Digital's systems
        will automatically activate a program you receive in a MAIL
        message.  Not every computer vendor's MAIL works this way, I
        suspect.  And, of course, you could set up a local mail processing
        system that would do this.  If you are using such a system that
        was developed by someone else, it could have a "trojan horse". 
        
        Tom

< Re: Note 655.104 by DR::BLINN "Avoid Career Limiting Decisions" >
        
>>  Some people are sending along versions that have all the headers
>>  removed (why do people do this?)

Well, I can't speak for the rest of your folks, but Tom, I have a
tendancy to remove headers from mail messages. Now before I am
hung out to dry let me explain. Often one gets mail messages like
a message that was posted in this notesfile sometime back, that 
are low on information content but high on the number of headers.
Seeing that I have been doing most of my Mail and Noting for the
past 1.5 years over a 1200 baud phone line I have a tendancy to 
get irrated at viewing more than two screens worth of headers 
before encountering the actual text of the message. If I were to 
forward a message like that, I usually would remove all headers
excluding the originators. And then I would add an informational
comment pertaining to the fact that numerous forwarding headers 
were deleted. 

I would guess that people believe they are doing the next guy a 
favor by removing the headers. 

Educate them, maybe on-line help or CBI as that which is provided
by NOTES would help...

/Ted
        

Removing forwarding headers makes sense.

Removing the originator's name (and/or headers) does not make sense.

    There are some favorite holiday pranks like sending mail messages with
    embedded escape sequences that lock up your terminal, specifically the
    VT100.  Others create visual images that make your terminal "appear" to
    be doing something it shouldn't (like deleting your files).  
    
    None of these programs cause any harm that can't be rectified by simply
    turning the terminal off and back on.
    
    Its obvious to the more computer literate types that EXTRACT TT: can't
    really hurt anything seriously.  However, these prank messages have a
    tendancy to end up in the mailboxes of people that don't understand
    that, and panic ensues.  
    
    I remember one panic message that went around the ENET from someone
    that THOUGHT thier account had been damaged by such a mail message and
    was warning others about this "letter bomb".
    
    Tom is right.  Mail can't hurt you unless you let it.
    
    Jim
    

        Like John Covert says, removing some of the intermediate path may
        make sense (as long as you keep a copy of the message to be able
        to show how it appeared to reach you, in case there is ever any
        question about its authenticity, since every person who touched it
        had a chance to modify it), but removing the identification of the
        originator makes no sense.  In the MAIL message I posted earlier,
        ALL headers had been removed.  All that was left was the message. 
        
        Clearly, I've just stated what I consider to be good practice --
        if you're going to forward something that you've edited (even to
        remove forwarding headers), keep a copy of the original.  That
        way, if anyone ever approaches you about the message, you can show
        where you got it from and what it looked like. 
        
        It gets better:  Here's one where I've removed some of the names
        to protect the guilty.  This is really the height of paranoia.
        While there is some risk (negligible in most cases) that a MAIL
        message containing bizarre escape sequences could mess up your
        terminal or terminal emulator, this is beyond the pale.  It says: 
        
During the next few weeks, Valentine messages may be sent to you with
instructions to type EXT TT.  In the past this method has been used
to transmit electronic intrusions that have corrupted programs/files
on the systems.

Most of the messages are OK, however, there is no way to know which
message carries an intrusion.

        There is no way I can imagine that such a message could comprise
        an "electronic intrusion" that could "corrupt programs/files on
        the systems". 
        
        Crying "Wolf!" like this tends to lead to people disregarding the
        legitimate security messages.  People with even a modicum of
        technical knowledge can see through this sort of warning to the
        underlying paranoia. 
        
From:	One well meaning person
To:	@extensive distribution list
CC:	
Subj:	Mail from <source> RE: VALENTINE DAY GRAPHICS.. thanks, <owmp>

From:	Another well-meaning person
To:	Person above
CC:	
Subj:	Please send this to everyone in <some> Group. Thanks <awmp>

From:	Yet another person (in a different group?)
To:	List of six people
CC:	
Subj:	Warning concerning Valentines Day graphics.....
[obviously, some headers were removed in here]
Subj:	FYI - SECURITY WARNING

From:	Person in CSSE, judging by the node name

Subj:	CSSE HOLIDAY SECURITY MESSAGE

From:	NAME: Fairly senior CSSE manager
	FUNC: CSSE                    
	TEL: His DTN and mail address
To:	See Below
CC:	See Below





From:	NAME: Same manager
Date:	26-Jan-1989
Posted-date: 27-Jan-1989
Precedence: 1
Subject: CSSE HOLIDAY SECURITY MESSAGE
To:	Same manager (forward from VAXmail, apparently)


From:	Yet another CSSE manager
To:	3 distribution lists
CC:	
Subj:	CSSE Holiday Security Message



It has been recommended by the Security Manager that this message be 
sent to all employees.  Please distribute to your employees.

During the next few weeks, Valentine messages may be sent to you with
instructions to type EXT TT.  In the past this method has been used
to transmit electronic intrusions that have corrupted programs/files
on the systems.

Most of the messages are OK, however, there is no way to know which
message carries an intrusion.

Please do not execute or forward any of these messages.


To Distribution List:
[removed]

  Since it's being suggested again that wise users examine suspicious
  COM files before executing them, let's also suggest again that one
  should NEVER fall for the "Hey, buddy, just do TYPE @FOO.DAT to see
  this neat file" trap.  TYPE @FOO.DAT is dangerously different from
  TYPE FOO.DAT; the "@" causes FOO.DAT to execute.

        RE: .109 -- Good point, Harry.
        
        RE: .107 -- Exactly.  You got yours in while I was composing
        mine.  
        
        Tom

    Forgive me if this self-referential warning has been given, but isn't
    the frequent mass distribution of gratuitous and simplistic warnings
    about "security" itself a subtle denial of service attack.

    From my point of view a message that tells me to ignore messages that
    _may_ be sent is itself a large sink of employee time.

    I got sent this warning twice, and declined to forward it in both
    cases.  Someone asked my opinion on it, and I at first thought it was
    silly, but I was wondering if one could use control sequences to load
    the answerback buffer with a command and then send the character to
    "type out" the answerback buffer.  How to get this to work well
    in MAIL, if it worked at all, is problematical.  Maybe someone more
    familiar with terminals can comment.
    
    On the whole, though, I consider unattributed memos like this that
    get forwarded all over the place to be a colossal waste of corporate
    resources.
    
    				Steve

    I believe some terminals allow you to load up the answerback message.
    In that case EXTR TT does become dangerous.
    
    Ypu just put an escape sequence into the mail message to say load
    up the answerback with:
    
    SPAWN do some naughty thing
    ^E
    
    When the EXTR TT finishes mail will get the command
    
    SPAWN do some naughty thing
    
    and hey presto
    
    some naughty thing
    
    is done in a subprocess.
    
    Also it could also load up UDKs (assuming they haven't been locked)
    with naughty things.
    
    Now my pet peeve, I hate security warnings that don't explain WHY
    something is dangerous. It is plain encouragement to ignore them.
    
    I believe my explanation, given above, together with more detail
    on which sort of terminals are vulnerable to this attack should
    have been attached to the 'Do not do EXTR TT' warning.
    
    By the way VT1xxs, VT2xxs and VT3xxs cannot have their answerback
    messages loaded by the host. I believe some VTxxx clones can and
    I'm not sure about the various terminal emulators.
    
    Dave

    I'm amazed that whoever originated that message about Valentine's
    day seemed to believe that just because something came from someone
    you know, it's safe.  
    
    Employees with few technical skills can easily forward anything,
    especially a holiday greeting.  (Most Extract TT's that I receive
    are from people who are new to the joys of on-line art).
    
    Holly