|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T c
Length: 39182 (0x990e)
Types: TextFile
Names: »christmas.exec«
└─⟦4f9d7c866⟧ Bits:30007245 EUUGD6: Sikkerheds distributionen
└─⟦this⟧ »./papers/Virus/christmas.exec«
\f
From: Will Martin __ AMXAL_RI <wmartin@almsa_1.arpa> 4-MAR-1988 18:47
To: Clement Taylor <CGTAYLO%erenj.bitnet@rutgers.edu>
Subj: [40970] Re: BITNET Security
[Moderator note: part 1 of 2. _H*]
Here is a compilation of data on the CHRISTMA EXEC virus which I collected
from postings in the RISKS Digest:
Regards, Will Martin
***Begin Included Messages***
From: minow%thundr.DEC@decwrl.dec.com (Martin Minow ML3-5/U26 223-9922)
Date: 11 Dec 87 11:55
Subject: Yet another virus program announcement fyi
From CRTNET, number 115. From T3B%PSUVM.BITNET.
Subject: Christmas Virus Warning
If you are at a CMS site and receive a program called CHRISTMA EXEC, please
(a) warn your postmaster and (b) discard the exec (or keep a copy for the
postmaster to look at, but DO NOT RUN IT). This exec paints a Christmas
tree on your screen and then sends itself to everyone named in either your
NAMES or NETLOG files. The result is potentially serious stress on Bitnet
and on your local spool system, and possibly a few system crashes here and
there as the number of reader files soars and exceeds the maximum. The
Christmas tree isn't all that pretty, and the joke is pretty mean.
A word to the wise. Your postmaster will thank you. Michael Sperberg-McQueen
------------------------------
From: davy@intrepid.ecn.purdue.edu (Dave Curry)
Subject: IBM invaded by a Christmas virus
Date: Sat, 12 Dec 87 10:02:24 EST
(From the Lafayette (Indiana) Journal & Courier, December 12, 1987. Quoted
without permission.)
IBM Woes -- Computerized grinch jams the mail
BINGHAMTON, N.Y.- A computerized Grinch invaded IBM's electronic
mail Friday.
An illegal software-style so-called Christmas card sent through
IBM's electronic mail jammed desk-top computer terminals, spokesman
Joseph E. Dahm said.
The so-called virus program forced plant officials to turn off
internal links between computer terminals and mainframe systems to
purge the message, Dahm said.
IBM sources say the link was off from 45 minutes to 90 minutes
depending on the location.
The program is known as a virus because it enters computer programs
and replicates itself automatically.
Curious employees who read the message titles "Christmas" in the
morning electronic mail discovered an illustration of a Christmas tree
with "Holiday Greetings" superimposed on it. A caption advised "Don't
browse it, it's more fun to run it."
"That was the hook," an IBM source said. "A lot of people thought
they could take a peek and then kill the message, but once opened, it
was too late."
The program automatically entered a security log listing contacts
made from the individual computer terminal, duplicated and mailed
itself to new victims.
Like a Pandora's Box, once opened, the program rarely accepted
commands to stop, sources said. Operators who turned off their
terminals to stop the Christmas message lost electronic mail or
unfinished reports not filed in the computer.
This article seems to have a lot of things in it that the reporter didn't
understand. I assume that the "terminals" in question are really PC's
connected to the mainframes; for one thing. Plus, I presume the "Don't
browse it" refers to the VM/CMS "BROWSE" command used for looking through
files, and not just to the regular English word.
Does anyone have any more info from a source which understands all the
big words?
--Dave Curry, Purdue University
------------------------------
Date: Mon, 14 Dec 87 09:38:55 est
From: Franklin Davis <fad@Think.COM>
Subject: IBM invaded by a Christmas virus
This article seems to have a lot of things in it that the reporter didn't
understand. I assume that the "terminals" in question are really PC's
connected to the mainframes; for one thing.
Probably the users were connected by 3270 type terminals (or
emulations on a PC) which use a half-duplex block mode protocol. If
you turn off such a terminal your session is aborted, and you lose
current edits. It is also very difficult to interrupt an executing
program, since it "owns" the line. There is a "system-attention" key,
but a busy system may take literally minutes to respond. (I'm glad I
don't have to use an IBM mainframe any more!! :-)
--Franklin Davis Thinking Machines Corp. fad@think.com
------------------------------
Subject: IBM Xmas Prank
Date: Fri, 18 Dec 87 10:03:57 -0500
From: Fred Baube <fbaube@note.nsf.gov>
From Friday's Washington Post, excerpted without permission.
"The message popped onto desktop screens in IBM offices around
the country and even crossed the Atlantic and Pacific oceans,
showing up in IBM outposts in West Germany, Italy and Japan."
[as pictured X
in the article] X X
X X X
X X X X
X X X X X
X X X X X X
X X X X X X X
X
X
X
A very happy Christmas and my best wishes for the next year.
Let this run and enjoy yourself.
Browsing this file is no fun at all. Just type Christmas.
________
"The message that bedeviled IBM was a comparatively benevolent
one and did not, as computer tricksters' creations sometimes do,
destroy other material in the system .. [although] rapidly
producing electronic gridlock."
"The culprit is unknown .. but preliminary investigation suggests
that the message originated outside the company. IBM's mail
system is attached to those of several other institutions."
"From start to finish, the message survived only hours .."
"Does the world's biggest and most advanced computer company feel
embarassed about its Christmas chain ? 'We didn't want it to
happen, but we anticipated something like this might be attempted
and we were prepared to deal with it.'"
Questions:
(1) An incoming message can contain an executable program,
that can easily be run ?
(2) Such a message can be remailed under its contained program's
control, presumably with the name of the last victim in the
"From:" field ?
(3) Can IBM trace it to an originator, or was anonymity possible ?
(4) How/where can readers of RISKS submit something similar ?
(strictly for professional testing purposes)
(5) Is the Internet similarly vulnerable ?
The prank seems to be benign, and therefore beneficial.
IBM seems to have dealt with it effectively (or have they ?).
Browsing this message is no fun at all. Just type Christmas ..
[Bay Area folks can read a long front-page article by John
Markoff on viruses in today's SF Chronicle-Examiner. PGN]
------------------------------
Date: Mon, 21 Dec 87 15:22:26 EST
From: Ross Patterson <A024012%RUTVM1.BITNET@CUNYVM.CUNY.EDU>
Subject: Re: IBM Christmas Virus
There have been several messages to RISKS lately about the
CHRISTMAs EXEC virus on IBM's network. This was an extension of the
same problem on BITNET and its European counterpart, EARN. Since I
raised the general alarm about it, I'd like to answer a few questions.
The virus used two standard CMS files, called NAMES and NETLOG, to
help it infect other users. The NAMES file contains a list of userids
and system names that you correspond with frequently, allowing you to
abbreviate them to a mnemonic nickname when sending mail, files, or
interactive messages. I composed this mail by sending to "RISKS",
which my NAMES file lists as user RISKS on system KL.SRI.COM. You can
also list phone numbers, paper addresses, etc. There is a commonly
available program that will print off a personal phonebook from your
NAMES file ("Traveling Sidekick" from the days BB - Before Borland).
The NETLOG file lists all users you've sent mail or files to, or
received them from. It's a very nice audit trail when you're trying
to remember where you got that copy of Space Wars.
After typing the Christmas Tree on your terminal, the virus
proceeded to read both the NAMES and NETLOG files to get a set of
target addresses. It then sent a copy of itself to each of them, and
finally deleted itself.
>I assume that the "terminals" in question are really PC's
>connected to the mainframes; for one thing.
The terminals mentioned are generally IBM 3270's, and PC's with
IRMA-type cards. The virus ran on the host system, not on the PC.
>Plus, I presume the "Don't
>browse it" refers to the VM/CMS "BROWSE" command used for looking through
>files, and not just to the regular English word.
Both, actually. The intent was obviously to stop the reader from
going further down into the file, where the real purpose of the
program was quite obvious. The language used (IBM's REXX) is usually
interpreted, so the program was sent in source form. Anyone who
bothered to read below the second screen-full (like all of us paranoid
Systems Programmers) began to see the trouble. It was slightly
cloudy, as all the variable names were in German, but seeing was fair
to good.
>The culprit is unknown
That is no longer the case. The culprit has been tracked down,
and barred from access to his/her system. A note to that effect was
broadcast to a number of mailing lists by the General Secretary of
EARN. The source system had recently been attached to the West German
section of EARN, and the user who started it all only intended to send
a greeting to a few friends. To quote a TV commerical, "... and
they'll tell two friends, and so on, and so on, ...".
> .. but preliminary investigation suggests
>that the message originated outside the company. IBM's mail
>system is attached to those of several other institutions."
Quite so. No one seems quite sure which of the gateways between
BITNET/EARN and IBM's internal network, VNET, passed the first copy of
the virus. It matters very little, since it found the VNET
environment even more conducive to reproduction than BITNET/EARN.
VNET'ers apparently keep much larger NAMES files than BITNET'ers. It
wasn't long before the links were carrying more CHRISTMA EXEC's than
anything else.
>"From start to finish, the message survived only hours .."
Per copy, perhaps. The first known instance of infection was at
about 1300 GMT on Wednesday, December 9. Within BITNET, it was
generally stamped out by the following Monday, December 14. On VNET,
it didn't show up until a day later, and was mostly killed in a
massive network shutdown on Friday.
>(1) An incoming message can contain an executable program,
> that can easily be run ?
Yes. Please remember that the Internet is not the only network
style in the world. In BITNET and VNET, mail is just another case of
file transfer. File transfer is performed by the sender, not the
receiver. These are store-and-forward networks, so the path from
system A to system B need not be intact for the duration of the
transfer. The viral program was transferred as a normal file, not as
mail.
>(2) Such a message can be remailed under its contained program's
> control, presumably with the name of the last victim in the
> "From:" field ?
It wasn't mailed. Thus, there wasn't any From: field, etc. It
did carry the system name and userid of the most recent victim, but
not any trace-back information.
>(3) Can IBM trace it to an originator, or was anonymity possible ?
A task force of BITNET and EARN systems programmers traced it back
to its source, by the usual disease-control procedures:
Doctor: "Miss X, you've got a nasty case of viral <Y>. Who have
you had contact with recently?".
Miss X: "Just a moment, I'll check my notebook."
A byproduct of the tool used to transmit the virus is an entry in
the NETLOG file listing the userid and system name of anyone it was
sent to, making it easier than usual for Miss X to remember. In some
cases, the user had suppressed the NETLOG facility, but that is the
exception, not the rule.
>(4) How/where can readers of RISKS submit something similar ?
> (strictly for professional testing purposes)
Noplace safely. Please don't try it on anything but an isolated
network, and then coldstart your spool afterwards.
>(5) Is the Internet similarly vulnerable ?
Not to this one. It plays on several things that the Internet
doesn't have:
1) A large number of IBM VM/CMS systems. The program would only
run in a CMS environment. There is no reason one couldn't write
something similar in any other language, though.
2) A suitable file transfer system. FTP doesn't apply. It must
provide a way for a user to receive an unsolicited file, in a
runnable form.
3) A good method of determining targets. The CMS NAMES and NETLOG
files provided an excellent source of information. I suppose in
a Unix environment, ".alias" and "/etc/aliases" would be ok, but
.alias is comparatively rare, while NAMES files are almost
universal in CMS.
>The prank seems to be benign, and therefore beneficial.
That is being debated in several circles. I, for one, agree with
you.
>IBM seems to have dealt with it effectively (or have they ?).
Yes, they have.
>Browsing this message is no fun at all. Just type Christmas ..
The lesson of this one is the same as for PC viruses: Never run
something you don't recognize. When the virus first appeared, several
people suggested that it was the work of students, and that it might
be used negatively in an ongoing argument over whether students belong
on BITNET. When we heard that "professionals" inside IBM were also
running programs they didn't recognize, that particular suggestion
vanished.
This virus was quite sly, in that by sending itself to people
listed in your NAMES and NETLOG files, those people would recognize
the source (you) as a friend, and be generally less inquisitive, until
things got nasty. Lesson #2: Even your friends sometimes make
mistakes.
Ross Patterson, Rutgers University
[RISKS received an unusually large number of messages on this subject --
from Fred Baube, John Owens (2), Allan Pratt, Anne Louise Gockel, and
Bruce O'Neel. I started trying to edit them down, but rapidly gave
up that strategy -- inordinate overlap. So, I will take a new tack,
which is to put out Ross' message -- which was the most comprehensive --
and then give Fred, John, Allan, Anne and Bruce first priority if THEY
wish to comment marginally or additionally thereupon. Please be terse
-- and avoid replicating ALL of the foregoing text in your messages,
as some of you have been doing. (One of the joys of mailers?) PGN]
------------------------------
Organization: The MITRE Corp., Washington, D.C.
Subject: The Christmas Card Caper, (hopefully) concluded
Date: Mon, 21 Dec 87 11:45:03 EST
From: Joe Morris (jcmorris@mitre.arpa) <jcmorris@mitre.arpa>
The following item was posted on the VMSHARE bulletin board. It describes
the origin of the CHRISTMAS EXEC file, and makes valid points about the
inability of computer systems to automatically recognize some types of
ill-behaved programs quickly enough to prevent damage to a network.
(VMSHARE is a closed bulletin board operated for the use of VM installations
who are members of SHARE, the large IBM mainframe user group. Shadow copies
of the VMSHARE traffic are distributed to many other nets, including VNET
and BITNET.)
Joe Morris (jcmorris@mitre)
Append on 12/19/87 at 20:10 by Melinda Varian <BITNET: MAINT@PUCC>:
The following statement, from a member of the EARN Board, answers the
queries about the origin of the CHRISTMA EXEC. Clausthal-Zellerfeld
is quite a new VM installation. When Heinz Haunhorst, of their staff,
was notified that the first appearances of the virus on the networks
originated at his node, he pursued the matter vigorously and skillfully.
Helmut Woehlbier, of the Technical University of Braunschweig, also did
an excellent job in helping to determine the originating node.
<> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 16 Dec 87 18:33:58 GMT
Sender: EARN Technical Group <EARNTECH@EB0UB011>
From: Michael Hebgen <$02@DHDURZ1>
Comments: To: EARN Executive <EARNEXEC@IRLEARN>,
EARN Board of Directors <EARN-BOD@IRLEARN>
Comments: cc: German EARN Executive <DEARNEX@DHDURZ1>,
German EARN node administrators <DEARNADM@DEARN>,
Heinz Haunhorst <HENRY@DCZTU1>,
"Dr. Gerald Lange" <LANGE@DCZTU1>,
Otto Bernd Kirchner <KIRCHNER@DS0IBM1>
To: Melinda Varian <MAINT@PUCC>
Subject: CHRISTMAS EXEC
Dear colleagues,
after some very sophisticated detective work it is clear that the origin
of the CHRISTMAS EXEC is the EARN node DCZTU1. A student there has writ-
ten this EXEC to send christmas greetings to his colleagues and another
student has used it without knowing what he is doing (as many of our
network users) and started the explosion.
The node DCZTU1 has already blocked the Userid of the author and done
all necessary steps. Every node in the network can be the next starting
point of a similar explosion and distribute virus programms or other
bad things.
As far as I know the EDP-systems there is no way to prevent users from
their own mistakes. The only solution I can think of for this type of
behaviour is to observe "EDP-hygiene":
If you receive an executable file (EXEC, CLIST, program) from another
might be unknown user do NOT execute without control because it
can result in gross missdemanour and serious damage.
Check all EXECs/CLISTs, what they are doing, before you execute them
and check all executable programs, where they come from and what
they do.
As in normal life uncontrolled behaviour may result in serious
consequences (I am not going to mention AIDS). You as a user are
responsable for all what you are doing.
I propose to include such statements (in better english formulation) into
the CODE OF CONDUCT and to start an "enlightenment" process for the end-
users
Best regards, merry christmas (without tree) and a happy new year
Michael Hebgen
EARN director of Germany and
General secretary of EARN
*** APPENDED 12/19/87 20:10:47 BY PU/MELINDA ***
ADDED NOTE FROM JOE MORRIS:
Did any contributor suggest how the message jumped from EARN (or BITNET) into
VNET? Supposedly the gateways (one at Yorktown, I believe) are monitored
closely so that the ability of a message to cross without supervision
is quite limited. I'm told that a few years ago there was something of a
major flap when a meeting of relatively high IBM brass was shown a message
Melinda Varian (the BITNET source of the EARN message I forwarded) had sent
to an IBM'er via VNET (WITH the permission of IBM...upper management in IBM
just hadn't been aware of the arrangement). My guess would be that it came
through an account on a customer machine but assigned to an IBM'er who could
pass mail into the IBM network.
Thought for the week: was this supposed to be a demonstration of a computerized
Christmas distribution TREE?
Second thought on the word "tree" (swiped from an undergraduate thesis at
MIT from the 60's):
Problems are posed by fools like me,
but only heuristics can search a tree.
Joe Morris
\f
From: Will Martin __ AMXAL_RI <wmartin@almsa_1.arpa> 4-MAR-1988 18:47
To: Clement Taylor <CGTAYLO%erenj.bitnet@rutgers.edu>
Subj: [40970] Re: BITNET Security
[Moderator note: Part 2 of 2. _H*]
From: Una Smith <0402909%pucc.bitnet@RUTGERS.EDU>
Subject: The Virus of Christmas Past (Re: RISKS-5.80)
To: comp-risks@RUTGERS.EDU
Re the discussion of receiving run-able mail files (sometimes viruses)
via BITNET.
A few years ago I received 2 pieces of mail, an XMAS EXEC written in
EXEC2 and a compiled module of some sort. The module was hard to break
into, so no one I knew then knew how to tell what it did without running
it. Well, it was a very nice, benign bug:
First, it imitated all the usual system messages one gets when logging off,
up to the full-screen VM370 logo. Then, slowly, the logo disintegrated
into a night time scene of a cottage on a snowy hillside under some pine
trees, smoke floating out of the chimney (the "smoke" was made up of
phrases; "s..m..o..k..e" and "M..e..r..r..y...C..h..r..i..s..t..m..a..s",
etc.), and snow flakes "*" falling from the sky. Elapsed time: about
5 minutes. Then it quit, abruptly leaving you sitting in front of a
terminal in some dingy office or terminal room, just as you were before.
The clue to this so-called Christmas card's origin was that the usual
machine name in the lower right was replaced with, if I remember
correctly, PSUVM. Has anyone on the net now got an old copy of that
somewhere? I didn't keep mine.
------------------------------
From: Skip Montanaro <steinmetz!montnaro@uunet.UU.NET>
To: risks@csl.sri.com
Subject: Re: IBM Christmas Virus (RISKS 5.80)
>(5) Is the Internet similarly vulnerable ?
>>Not to this one. It plays on several things that the Internet doesn't have:
The quasi-equivalent of this problem in UNIX systems (and most of the
Internet, because of the large number of UNIX systems it contains) is the
ubiquitous shar file, an ASCII packaging machanism used to transfer code and
other ASCII files via mail and/or Usenet news transfer. The problem lies in
the way users unpack shar files: they execute them. Needless to say,
inspection of shar files before execution/extraction is highly recommended.
There's nothing to prevent me from writing a shar file that purports to be a
Christmas card. Execution of it might display the card, check out the contents
of various mail-related files, (like ~/.mailrc and ~/mbox) looking for likely
candidates to send the shar file, then recursively send it.
In fact, the same scheme would work for most operating systems with a
command language that could be executed from a file. UNIX systems are
especially vulnerable, however, because of their large numbers.
Skip (montanaro@ge-crd.arpa, uunet!steinmetz!sprite!montanaro)
------------------------------
From: msb@sq.com (Mark Brader)
To: risks@csl.sri.com
Subject: Another article on the Christmas Virus [just in time for Xmas]
[In the spirit of the season, I am including this now rather old-hat
and somewhat ill-informed note for a few more background details. It
is interesting perhaps more for what the press can do to an incident
than for the incident itself. Happy holidays to all. RISKS will take
some vacation -- unless something really startling happens. PGN]
I have been handed a clipping from the (Toronto) Globe and Mail's "Report
on Business" section. I don't have the date, but Texaco Canada Inc. closed
at $31, up $4.50, on the other side of the page.
The clipping is of the Quidnunc column by Bud Jorgenson.
My !'s in square brackets.
Merry Christmas, Big Blue. The internal system of the world's
biggest computer company was disrupted for almost 72 hours by an
electronic Christmas card. IBM's public relations department
played down the seriousness of the incident, but according to
our mole at IBM, "it crippled us".
The computer equivalent of a nuclear meltdown [!] began at a
university in West Germany when someone tapped into [!] IBM's
Prof (PRofessional OFfice) System with a graphics-laden
Christmas message. Whether it was deliberate or a coding error
was not clear [!], but the card quickly became a hit and was passed
on to various routing systems.
As every computer buff knows, graphics use large bites of memory
and this one gobbled up an ever expanding chunk of the Prof
System as it multiplied its way through IBM offices. This was
a week ago Friday, just before quitting time in Europe and
during the first half of the workday on this side of the water.
When the system goes down, IBM simply cannot work because just
about everything is dependent on the [!] computer, right down
to daily diaries with meeting schedules. By early Monday,
the system in Canada was partly restored so that employees
could tap into the data base to read files.
But they couldn't use printers or communicate with other offices
until the all-clear was sounded, which was after 10 am Eastern
time. An IBM spokesman said the impact on operations varied
from country to country.
Police work to track down the culprit was turned over to Bitnet
and Earn, a pair of computer networks that link universities in
North America and Europe. The list of suspects has been
narrowed to two at the Technical University of Clausthal,
a small town south of Hanover.
Forwarded by Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb
------------------------------
From: Eric Skinner <ERS2F%UOTTAWA.BITNET@CUNYVM.CUNY.EDU>
Subject: Christmas Exec AGAIN!
To: RISKS@csl.sri.com
An interesting point that has not been mentioned so far is that, at least in
the version that reached BITNET sites in Canada, there was a major bug in the
code of the program. It parsed the NAMES file in a very inflexible way causing
it to have a success rate of about 5% at coming up with valid forwarding
addresses.
If the programmer had been more careful, we might have been in an even bigger
mess.
So there are fewer risks when a program has bugs? :-)
Eric Skinner, Computing Centre, University of Ottawa
------------------------------
From: minow%thundr.DEC@decwrl.dec.com (Martin Minow)
To: risks@csl.sri.com
Subject: The Christmas Virus [end of the season?]
The same comments on the virus from a slightly different (vms) point of view.
The only new info is the description of the anti-viral software. Martin
[Pardon a little initial redundancy. I did not want to edit. PGN]
Newsgroups: comp.os.vms
Path: decwrl!ucbvax!QUCDNSUR.BITNET!PYM
Subject: CHRISTMA comes but once a year, a virus may be forever.
By now, many of you will have heard of the (infamous) CHRISTMA EXEC
"virus" which infected BITNET/EARN/NETNORTH and virtually paralyzed IBM's
internal network for a day or two. For those who haven't seen the
various postings on the BITNET LINKFAIL list, RISKS-FORUM Digest, etc., I
will summarize (no flames for the oversimplifications in the interest of
brevity, please). Originating as a "prank" on a German end-node on EARN,
this EXEC (i.e. similar to a .COM file - and written in REXX, a DCL-like
language) displayed, when executed on an IBM VM system, a primitive
christmas tree on the terminal and then mailed itself to everyone on that
poor user's NAMES file (i.e. personal mailing name list) before deleting
itself. Of course, some users had network distribution lists (e.g.
JNET-L, MEDINF-L, etc.) defined in their NAMES file . . . [I
personally received six copies of this EXEC from different sources - this
is probably not unusual.]
While this was a significant problem on BITNET/EARN/NETNORTH with a
fair number of VM/CMS nodes, the virus clearly could not infect VAXinated
nodes, of which there are a larger number. Also, many (usually
undergraduate) students on VM/CMS systems are denied network access, thus
limiting the rate of spread of the virus beyond an infected system.
However, once the virus entered VNET, IBM's internal network of VM/CMS
systems, things really took off (all VM/CMS systems; users with large
NAMES files; all with network access) and allegedly brought their
network to a standstill.
Initially, the problem required manual intervention by system
managers to purge CHRISTMA EXECs from users' readers - but this could
only give a temporary remission in the disease. Fortunately, a CHRISTMA
eradicator was written (by Eric Thomas, author of the LISTSERV software),
and also an ingenious virus was developed (by Hank ?, sorry, I've
forgotten) to follow and destroy the original CHRISTMA virus and then
self-destruct in mid-January. So now it's eradicated like smallpox:
hmmm . . . I expect that there may be another minor epidemic when some
users return from vacation.
So, what should we do? Laugh at IBM? Say "It can't happen to me."
Look at all those experienced, computer-wise IBMers who ran CHRISTMA
EXEC. Oh yes, there will be flames . . . platitudes about NEVER using
any software which you haven't written yourself - or is written by
someone you TRUST ABSOLUTELY :-) . . . flames about chain letters
and viruses on the network . . . their authors should be boiled in oil
/ set in RA81 air filter glue / sentenced to do 10 years of RSX SYSGENs /
locked in a room with only an IBM PC / (substitute your favourite
nightmare here). Let's just think a little before flaming.
Could a "harmless" CHRISTMA-like virus attack a VAX/VMS system? A
recent network posting (RISKS?, LINKFAIL?) mentioned the possibility of a
virus hidden in SHAR files which are _executed_ as .COM files to unpack
them. SHAR files are, after all, an excellent method for _reliable_
software distribution over gateways. (This is not meant to reflect
negatively on Michael Bednarek in any way - VMSHAR is a great
contribution and we all have used it or will use it.) But . . . nobody
unpacks one of these distributions with PRIVs turned on, do we? Could
such a virus, like CHRISTMA EXEC, replicate from a non-privileged account
(apart from doing a SET PROC/PRIV=ALL quietly in the middle of the file)?
Certainly, VMS Mail won't allow wildcard SEND (and JNET won't allow a
wildcard SEND/FILE), but, for example, a .COM file could do a SHOW
LOGICAL/OUTPUT=CRACKER.TMP, look for logicals with syntax "jnet%",
"BITNET%", "IN%", etc. and try mailing itself to these addresses. (No
flames about giving state secrets to the enemy, please. Blind Freddy
could have seen that one.)
We may not be able to read a SHAR file in its entirety (looking for
a virus in a few thousand blocks of code), but I for one am certainly
going to "quarantine" it as far as possible, SEARCHing it for more than a
few key words before unpacking it from a non-privileged (either default
or authorized) account. Further suggestions from the more devious minds
on the list would be welcome, please. Ignorance may be bliss, but it is
definitely NOT SAFE.
Most if not all of us have public domain software running on our
systems - or programs written by students and our colleagues
(trustworthy, of course :-} ). How many VAX/VMS systems do _not_ use at
least one piece of DECUS software? This PD software, even if not
essential, makes life easier and/or saves hours of work. Software
exchange isn't going to stop now, nor should it. We must be vigilant,
both for our own safety, and as a responsibility to colleagues on the
network. We must make all reasonable efforts to check before executing
software ourselves or posting it to the net - or making it available for
FTP or putting it on a BITNET LISTSERV. CHRISTMA EXEC comes but once a
year, but a virus can be forever.
Comments from the Info-VAX gurus would be appreciated. What are the
guidelines for "safe software exchange"? What are the best methods of
checking software for viral contamination, granted that we are going to
continue to exchange it?
John Pym
------------------------------
Date: Mon, 4 Jan 88 07:51 EDT
From: "guthery%asc@sdr.slb.com" <GUTHERY%ASC%sdr.slb.com@RELAY.CS.NET>
Subject: Source Code is Counter to Viruses & Trojan Horses
To: risks@csl.sri.com
As a little bit of reflection about the fact that almost all computers have
clocks in them will show, there is no protection in trying programs out with
write-only harddisks or with privileges turned off. Doing this only sets
the hook deeper. In fact, anytime you run a program whose complete
workings you do not and cannot understand you are at the mercy of the author
of the program and you are at risk.
One very good way to counter viruses and trojan horses is to insist on getting
the source code of any program you run. This is summarized in the following
pocketsize adage:
IF YOU CAN'T READ IT, DON'T RUN IT
There are NO good reasons why software vendors shouldn't give you the source
code of any program they sell you. The reason they don't currently is because
you could see what a mess the program really is. In 999 cases out of 1,000
they don't know everything the program does and they certainly don't want you
looking over the code and telling them.
For a moment stop and think of all the execute only software you run on
your system. Think of all the companies from whom you purchased this
software. Think of all the pressure you put on them for bug fixes, new
features, and lower prices. Think about the translation of these pressures
into pressures on programmers. Suppose one of these programmers decides to
get just a little even ... an occassional bad number, a lost record once a
month, a couple pennies moved from here to there just for fun, a scrambled
directory entry once in a blue moon. If the program does what it purports
to do, where is the check? The project leader? The manager? The president?
The venture capitalist? You? And who is responsible? You! And what can
you do with a bunch of object code? Turn off the harddisk? Scan the program
for strings? Deny privileges? Piece of cake!
We are marginally able to answer the question "Does this piece of software
do what I want it to do?" but we are absolutely incapable of answering
the much more important question "Does this piece of software NOT do what
I don't want it to do?" Through this gaping hole in our capabilities enter
viruses and trojan horses. It is historically interesting that I can get a
handle on the first question without the source code but I can get nowhere
on the second without it. As long as we willing to accept programs from
software suppliers without the source code we, irresponsibly in my view,
accept undue risk and invite disaster.
------------------------------
From: bryce%hoser.Berkeley.EDU@ucbvax.Berkeley.EDU (Bryce Nesbitt)
Subject: Viral VAXination? (Re: RISKS-6.1)
Date: 4 Jan 88 07:52:09 GMT
>Could a "harmless" CHRISTMA-like virus attack a VAX/VMS system? A
>recent network posting (RISKS?, LINKFAIL?) mentioned the possibility of a
>virus hidden in SHAR files which are _executed_ as .COM files to unpack.
I'm surprised nobody has mentioned this: Around here we don't "execute"
shar files to unpack them. Instead there is a handly little utility called
"unshar". I use a version on both Unix and my Amiga microcomputer. It
internally handles all of the "legitimate" commands that a simple file packing
shar might contain (echo, wc, cat, if, test, #, exit, etc.).
It is much less vulnerable to attack. To use the example of the poster, unshar
would simple report "unknow command" if a "SET PROC/PRIV=ALL" was quietly
inserted in the middle of the file.
The comp.sources.unix and comp.sources.misc archives undoubtably have C
source code for the taking.
bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci")
------------------------------
Date: Tue, 05 Jan 88 08:44:54 EDT
From: Jeffrey R Kell <JEFF%UTCVM.BITNET@CUNYVM.CUNY.EDU>
Subject: Christmas virus plus
The problem is compounded on IBM VM/CMS systems (where CHRISTMAs EXEC took
its toll) by an often overlooked "feature" of the standard IBM "receive"
command. Files such as EXECs are usually sent in a special encoded form
called NETDATA format. The "receive" command is smart enough to determine
the format of the file and decode it appropriately, as is the "peek" command
used to browse a file before receiving it. BUT... the NETDATA encoding also
allows for multiple files to be combined into one NETDATA stream. The file
appears with only the attributes of the first file in the stream, and only
the first file appears when "peeked". When the unsuspecting victim performs
the "receive", the remaining files are ALSO received with REPLACE IMPLIED!
Building such a "nested" NETDATA deck is not common knowledge, but can be
done using the undocumented internal module used by sendfile/receive. The
now infamous CHRISTMA EXEC could just as easily contained a PROFILE EXEC
behind it that would format your A-disk the next time you logged on. Thus
even if you did read the source code for CHRISTMAs and trashed it upon
discovery of its function, your next logon would result in erasure of your
entire A-disk (and also any evidence of what caused it to occur).
There is a semi-public-domain overlay for RECEIVE available on any Bitnet
NETSERV server which detects multiple datasets in a NETDATA stream. Any
concerned IBM CMS user out there should investigate this utility.
------------------------------
From: ahh@j.cc.purdue.edu (Brent L. Woods)
Date: Tue, 5 Jan 88 9:14:35 EST
Subject: Unshar program (was: Viral VAXination [Risks 6.2])
>I'm surprised nobody has mentioned this: Around here we don't "execute"
>shar files to unpack them...
This probably should have been mentioned earlier, as I'm sure it's
of interest to quite a few people. I can't speak for either the
comp.sources.unix or comp.sources.misc archives (though, as a side note,
I couldn't find any unshar programs in the comp.sources.unix archive
that is maintained here at Purdue), but there *is* an unshar program in
the comp.sources.amiga archives. I'm not absolutely certain, but I
believe that the version we have is the one that Bryce was writing about
above.
If anyone might want a copy of this program source code (in C),
it's available via anonymous ftp from j.cc.purdue.edu in the amiga
source archives (the directory it's in is news/comp/sources/amiga/volume1,
and the filename is unshar.c.Z). It's written with portability in mind,
so it should compile and run under a variety of systems, but we've only
tested it under UNIX and on the Amiga so far. Also, the file in the
archives is compressed (UNIX "compress" utility), so ftp should be set
to "binary" mode to insure a correct transfer.
Brent Woods, Co-Moderator, comp.{sources,binaries}.amiga
USENET: ...!j.cc.purdue.edu!ahh ARPANET: ahh@j.cc.purdue.edu
BITNET: PODUM@PURCCVM
------------------------------
***End of Included Messages***