RISKS-LIST: RISKS-FORUM Digest Saturday, 2 January 1987 Volume 6 : Issue 1
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents: [Partial cleanup on backlog, mostly security related]
The Christmas Virus (Martin Minow) [end of the season?]
Password security in multi-user systems (J. Eric Townsend)
Re: Program trading (K. Richard Magill)
DES and NSA's new codes (Tom Athanasiou)
Electronic Interference (Al Watters)
American Express security ... (Henry Mensch)
SSN / Phone Number / etc. on credit purchases (Jordan Hayes, David Albert)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, *NONREPETITIOUS*. Diversity is welcome.
Contributions to
[email protected], Requests to
[email protected].
For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j.
Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).
----------------------------------------------------------------------
From: minow%
[email protected]
(Martin Minow THUNDR::MINOW ML3-5/U26 223-9922)
Date: 29 Dec 87 09:57
To:
[email protected]
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: HRISTMA comes but once a year, a virus may be forever.
Posted: 27 Dec 87 22:39:00 GMT
Organization: The ARPA Internet
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
BITNET: PYM@QUCDNSUR Real life: Dr. John Pym
(POSTMASTER@QUCDNSUR) Department of Surgery
Telephone (613)549-3898 - office Queen's University
(613)548-4879 - home Kingston. Ontario
(613)541-7792 - cellular CANADA. K7L 2V6
Chairman, THISLUG (DECUS Thousand Islands LUG)
------------------------------
From: ucbcad!ames.UUCP!hoptoad!academ!uhnix1!nuchat!splut!flatline!erict@ucbvax.Berkeley.EDU
Date: Thu, 31 Dec 87 23:13:52 CST
To: splut!KL.SRI.COM!RISKS
Subject: Password security in multi-user systems
I am the systems administrator at a small software company here in Houston.
(Actually, we're right next door to NASA-JSC and in the McDAC building.
Anyway...)
McDAC is very, very, very security conscious. Armed guards and the like.
"Of course", you say, "it is because they deal in the highest of high
technology and in matters of national security."
I work for a small banking software company, Integrated BancSystems,
housed in the same building. We develop software that deals "only"
with things like loans, customer accounts, bank customer lists, etc.
Part of our product line is geared towards the latest fad (buzzword?):
LAN's. PC clone LANS, to boot.
Before we got our LAN for development, we developed on UNIX systems, which
I felt were secure enough for our purposes. Banks aren't a national security
problem, so they shouldn't require the high standards of security that our
upstairs neighbors have to take. The LAN's based on IBM PC compatible
computers (Novell SFT II v2.0a in particular) have just blown a huge,
gaping hole in the side of banking security.
I have no particular problem with Novell, and feel that they are
representative of the state of technology in PC compatible based
LAN's.
Point by point:
1. Passwords are not stored in an encrypted form. Any person that gains
the "supervisor" password, or has his "security equivalance" (sic)
raised to "supervisor"; can go into the "syscon" utility, pick
"User Information", pick a user's login name, and then pick
"Password". Voila'! The user's password, in ascii, for all to see.
(A friend claims he has broken the protection scheme that is used to
write them to the file server's hard-drive, but I have yet to see
him prove this on my system.)
[Again, other than this (rather glaring) problem, I think Novell has
done a rather fine job of making PC clones usable (to some limited
degree. :-) ) ]
2. Software products sold to banks are quite often very insecure.
I feel this is a very important issue that Data Processing managers
should look into. (Are they still called that in other businesses?)
An example:
The SMART software system -- an integrated package of "Spreadsheet",
"Communications manager", "Time manager", "Database manager", and
"Wordprocessor" -- advertises "personal file protection". There
are several problems with their implementaion of this idea.
1. Only wordprocessor files are actually encrypted with any
sort of encryption algorithim.
The spreadsheet files have their password stored within
the first 256 bytes of text. This pattern can easily be
discoverd by encrypting a file, then "dump"ing or "debug"ing
that file and examining what is actually written to the disk...
--> Or you can just look down a couple of blocks, where the
raw ascii spreadsheet is stored. <--
2. Cursory examination shows that the password used as an
encryption key is stored in the same way:
within the first 256 bytes of data, in a simply permutated
form.
3. [This problem is created by the user-unfriendly-ness of
the SMART system when implemented on a LAN. (It seems to
have been originally written for standalone PC, and not
modified to any great deal for LAN use.)]
Many system administrators tend to lump all the users in
"group" instead of "individual" directories, and then
direct users to "password" their files.
Reason:
It is rather involved to set up seperate SMART working
directories. Each user must have his own directory of
screen, printer, and keyboard drivers, along with 3 or 4
parameter files, a configuration file, and several other
miscellanious files. This eats up i-nodes (and their
equivalent), and takes a while to set up for a new user
and to remove for an old user.
I feel that these two reasons are more than enough to cause concern
about bank security.
I've only been into computing on a large scale (large = bigger than
a Commodore 64) for only a year or so, and I have been able to easily
defeat the security on programs sold to us.
Disclaimer: The problems listed above have been reported to the
management of my company. They agree that security is a very serious
issue, one that should be paid a great amount of attention and time.
Our software uses DES-style encryption in an effort to make up for
the intrinsic weaknesses in MS-DOS / IBM-PC compatable computer
security.
J. Eric Townsend ->{uunet!nuchat,academ!uhxnix1}!splut!flatline!erict
713-486-7820, 10am-6pm
------------------------------
Date: Mon, 28 Dec 87 15:48:39 est
From:
[email protected] (K. Richard Magill)
To:
[email protected]
Subject: Re: Program trading (RISKS-5.79)
Organization: Oxford, Ann Arbor
[Hugh Miller writes about replacing human judgment with machine
judgment with respect to computer trading programs]
>And how will we insure that such enormously complex systems
>will not synergetically go plooey when pushed to their volume or price limits?
We don't. They are self limiting much in the same way as icy roads
limit speed. Those who exceed, die.
Even if the minute to minute trading is done using machine judgement,
the day to day, or some long term, will be done by humans, even if it
is just when to turn the machine on and off. In the near future this
will mean trading strategies change daily and on a per company or per
trader basis. There would be no incentive to share software as
"winning" depends on doing better than the next guy.
If a company has the resources to "plooey" the market before they suicide,
well, what keeps that company in check now?
rich.
------------------------------
Date: Tue, 29 Dec 87 18:13:01 PST
From:
[email protected] (Tom Athanasiou)
To:
[email protected]
Subject: DES and NSA's new codes
The other day a posting included the phrase:
"...DES - has the analysis behind the design been made public yet?"
This reminded me. I looked into the whole DES controversy in some detail
about a year and a half ago. It may be out of date. Here's a summary:
In 1973, when the NBS called for proposals for a national encryption
system, IBM's LUCIFER system was already in the final stages of development.
It was good, by all reports so good that it upset the code-breaking side of
the NSA. Rather than approving LUCIFER as is, NSA modified it in several
strange ways to create DES.
LUCIFER's key size was 128 bits; DES had a key size of only 56 bits.
Thus, it is much more vulnerable to "brute force" attacks. There are
2**56 possible DES keys, and as large as this number may seem, it is tens
of millions of times smaller than the number of possible keys in ciphers
approved for military use.
NSA's weakening of LUCIFER appears to have been deliberate. According to
David Kahn, author of The Codebreakers, LUCIFER set off a debate within
NSA. "The code-breaking side wanted to be sure that the code was weak
enough for the NSA to solve it when used by foreign nations and companies,"
he wrote in Foreign Affairs. "On the other hand, the code-making side
wanted any cipher it was certifying for use by Americans to be truly
good." Kahn says that the resulting "bureaucratic compromise" made the key
shorter. Alan Konheim, former manager of IBM's LUCIFER research project,
recollects, "If they [NSA] had had their way, they would have had 32
bits...I was told at one time that they wanted 40 bits, and at IBM we
agreed that 40 was not enough."
At the same time that the NSA shortened LUCIFER's key, it used classified
criteria to redesign several numerical tables known as "substitution" or
"S" boxes. These S boxes control permutations that are key to the DES
algorithm, and NSA's critics have long suspected that the changes to them
might make the system vulnerable to a "cryptoanalytic" attack. In other
words, the boxes might conceal a trap door.
Despite repeated rumors, such a trap door has never been found. However,
mathematicians have unearthed several peculiar properties in the S boxes,
properties that were not present in IBM's original design. They have also
demonstrated the possibility of weakening the cipher by introducing hidden
regularities into the S-boxes. Still, no one has managed to use these
discoveries to mount a successful cryptoanalytic attack on DES.
The controversy over DES eventually subsided, but in late 1985 NSA suddenly,
and gracelessly, abandoned the cipher. Directly contradicting years of
reassurances, Walter Dealy, then NSA's deputy director for communications
security, told Science that he "wouldn't bet a plugged nickel on the Soviet
Union not breaking [DES]". People in the industry felt betrayed. According
to Herb Bright of Computation Planning Associates, quite an uproar ensued in
the normally quiet halls of the American National Standards Institute when
NSA announced new ciphers to replace DES.
These ciphers are designed to be distributed as pre-sealed and tamper-
resistant integrated circuits. The encryption algorithm hidden within the
chips is classified. It remains unknown even to engineers who work with
the chips. Critics feel that such secrecy offers NSA the chance to build
a real trap door into the chips. Herb Bright: "With a hardware black box
you can describe several schemes that would be almost impossible to test
for from the outside and could, in effect, constitute a hardware Trojan
Horse".
My conclusion? That NSA probably hadn't put a trap door into DES, but felt
that, what with all the heat it was taking anyways, that it might as well
replace DES with a cipher that really did contain a trap door. The new
cipher chips may indeed contain such a trap door, but so little is known
about their internals that speculation has been uninteresting.
Further, it is impossible -- in principle -- for the agency to exonerate itself
from charges such as these as long as it promotes ciphers based on secrecy
rather than algorithmic inpenetrability. Such ciphers do, I believe, exist
(I'm no expert) but that's another story.
-- Tom Athanasiou
------------------------------
Date: 29 Dec 1987 22:28-CST
Subject: Electronic Interference
From:
[email protected]
To:
[email protected]
The following is extracted from Aviation Week and Space Technology,
Dec 7, 1987, Vol 127, No. 23.
"Air Force Examines Effects of Microwaves on Electronic Systems" U.s. Air
Force Gypsy microwave device is being used to check the susceptibility of
electronic systems to currents induced by high-power microwaves, and to
investigate methods of increasing device efficiency. The Air Force's
Forecast 2 report listed high-power microwaves as a promising weapon and
there has been interest in the subject dating back over 30 years. Gypsy and
other microwave devices are being managed by the Air Force Weapons Laboratory
at Kirtland AFB, N.M., where more than 600 scientists and engineers held a
secret conference on high-power microwave technology last December (AW&ST,
3 Nov 1986, p. 151). Soviet physics publications also have shown an interest
in such devices. Gypsy can produce more than one gigawatt of power in short
pulses at several percent efficiency and can be tuned over 0.8 - 40 GHZ.
Gypsy uses the virtual cathode oscilator (VIRCATOR) principle, under which an
electron beam penetrates an anode mesh with a current density greater than
the space charge limiting value. The high negative charge beyond the anode
represents a virtual cathode, in which the electrons bunch in phase and
oscillate at stable frequencies. "
Al Watters
------------------------------
Date: Sun, 27 Dec 87 21:44:26 EST
From: Henry Mensch <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Subject: American Express security ...
I am a bit skeptical of American Express' verification methods, also.
Recently I decided that my AmEx plate was in sorry shape and I phoned
their toll-free customer service number to arrange for a new one.
After I made my request clear, I was transferred to another CSR who
asked me two questions (what SS# I put on my application, and
something else that I don't recall offhand now). After I answered the
questions, I was told that my replacement (new) card would arrive in
ten days (it arrived in three days).
Does this mean that anyone who knows a bit about me can get my AmEx
plate, too? Scary ...
# Henry Mensch / <
[email protected]> / E40-379 MIT, Cambridge, MA
# {ames,cca,rochester,harvard,mit-eddie}!garp!henry
[Coincidentally, Steve Anthony <
[email protected]>
asked Why are Mother's Maiden Names Required? PGN]
------------------------------
Date: Tue, 29 Dec 87 18:16:37 PST
From: Jordan Hayes <
[email protected]>
To:
[email protected]
Subject: SSN / Phone Number / etc. on credit purchases
Almost everyone who has talked about the question of "Why do stores want my
phone number on the charge slip?" have clearly never worked in retail sales
before ... something *always* goes wrong, and a phone number is a quick way for
the store to contact you. Sure, MasterCard doesn't require it, but remember
we're talking about (often) fast transactions by people who are paid very
little to make sure details are correct. I have been called at least a half a
dozen times to correct mistakes on those little charge slips. It has saved me
lots of time later when I would have had to correct the mistake with the VISA
or MasterCard company when my memory of the incident and my receipts were long
gone. I wish they didn't put my number on the same piece of paper as my
account number, but i'm glad they were able to get a hold of me.
/jordan
[Also commented on by James M. Boyle, and by Christopher Garrigues
<
[email protected]> who quoted at length <!> from /Why Do Clocks
Run Clockwise?/ by David Feldman, Harper & Row, 1987, and discussed
the return of forgotten cards... PLEASE BE BRIEF, GUYS... PGN]
------------------------------
Date: Fri, 25 Dec 87 12:09:40 EST
From:
[email protected] (David Albert)
To:
[email protected]
Subject: SSN Required Disclosures
Organization: Aiken Computation Lab Harvard, Cambridge, MA
>Organizations try circuitous ways to get the SSN. For example, when one
>gets or renews a driver license in California, he finds a place for
>inserting the SSN but without explanation....
I just had my passport renewed. On the renewal form, was a space for SSNs,
with the word "optional" in parentheses under the slot -- but the word had
been crossed out in pen. I asked the (post office) clerk why, and he told
me that giving my SSN was no longer optional. I assume that most people stop
asking questions after such a response, but I went on. I asked if the SSN
was essential to receiving my passport, and the clerk said no! He said that
if I did not put my SSN on the form, I would still get my passport, but that
the IRS would charge me a $5 penalty on my income tax returns.
Was the clerk making all of this up? The whole thing sounds very strange.
Or does any or all of his story have a basis in fact? I decided not to put
my SSN on the form, although if I was in a hurry to get the passport and
worried about delays, I might have included it to be sure the passport arrived.
The passport arrived about two-three weeks later, as expected, with no delays
and no warning about any future penalties. Does anyone have an explanation?
David Albert UUCP: ...{ihnp4!think, seismo}!harvard!albert
------------------------------
End of RISKS-FORUM Digest
************************