Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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.
>From: davy@intrepid.ecn.purdue.edu (Dave Curry)
>Subject: IBM invaded by a Christmas virus {RISKS 5.72}
> ...
>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.
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.
>Subject: IBM Xmas Prank {RISKS 5.79}
>From: Fred Baube <fbaube@note.nsf.gov>
> ...
>"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.
>...
>Questions:
>(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]
As I have not seen anything about this in RISKs yet ... The case brought against James McMahon, who was accused of placing logic bombs within the computer system used by Pandair Freight, has been thrown out of court because of "unsatisfactory evidence". The judge has ruled that there was no case to answer. This was reported in Computer Weekly dated December 17/24, 1987. It will be interesting to learn in what way the evidence was unsatisfactory. There used to be a problem in British law(and it may still exist) in that evidence could only be given by humans. Information generated by a computer without the explicit involvement of a human could not be used in court. I may have got this legal point garbled as I don't speak legalese. Geoff, UMRCC
If there is a legitimate need to study illicit code such as viruses and embezzlement routines, and not just a forensic need to try and track down the author, then there could indeed by a need for a repository. I suggest the model of the Center for Disease Control in Atlanta, which has samples of pathogens. However, note that there was (is?) a controversy surrounding CDC's wish to keep samples of smallpox, which, it is believed, has otherwise been eradicated from the face of the earth. Why leave one known source? Personally, I'd just as soon not have the code samples around. I'd just be tempted to play with them. (Disclaimer: I'm not a programmer.) [Program viruses, Trojan horses, etc., will never be competely eradicated. They tend to re-erupt spontaneously or be rediscovered. PGN]
To add my $0.02 to the conversation on Roger Boisjoly, I agree with Ronni Rosenberg, having seen a videotape of him telling his story. I seem to recall that he made reference to the same period of silence (the last time anyone called for objections to the launch) that Henry Spencer did. Boisjoly said that he was much too astonished at the decision to go through with the launch (despite his strong objections) to say anything at that point. He did not fully recover his senses until after the teleconference ended. I think that we can only expect the man to be human; we can't always act heroically when we're in shock... Stuart Freedman stuart@bkr.ceo.dg.com or rti!xyzzy!freedman@mcnc.org Data General Corp.(Mail Stop E-219), Westboro, MA 01580 +1(617)870-9659 Pick an e-mail address — any e-mail address...
In RISKS 5:79 Alex Heatley reports that he can establish a password of more than eight characters in the IBM VM system, but that on login the system truncates the entered password to eight characters, then (correctly) reports that it fails to match the one in the access control file. I don't know what security system his system uses, but IBM's DIRMAINT product, which is probably the most widely used directory maintenance facility used in VM installations, refuses to accept an oversized password. I just tried to enter one on our system, and was rebuffed with message DVHDIR017E. Joe Morris (jcmorris@mitre.ARPA)
The two competing local ATM cards in Pennsylvania are Cashstream and MAC. All the Pittsburgh banks with ATM cards are signed up for one or the other local networks. Cashstream is run mainly by Mellon Bank, MAC mainly by Pgh. National Bank. Both Cashstream and MAC extend into neighboring states. Meanwhile Cashstream is hooked up with the national ATM network called CIRRUS, while MAC is part of the national PLUS system. I've used my Cashstream card in CIRRUS machines in other faraway states, and I've used my MAC card in PLUS machines across the country. But I always assumed that these two kinds of cards were big competitors at each level : bank vs. bank, local net vs. local net, and national vs. national, and that the two sides wouldn't cross. But in New York, there are ATM machines which accept both MAC and Cirrus cards. I was surprised, since in Pennsylvania, MAC cards work in PLUS machines but not in Cirrus machines, as MAC's local competitor Cashstream is connected with Cirrus.
Please report problems with the web pages to the maintainer