RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (04/01/88)
RISKS-LIST: RISKS-FORUM Digest Friday 1 April 1988 Volume 6 : Issue 52
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
April Fool's warning from Usenet (Gene Spafford via Cliff Stoll)
Quebec Probing Leak of Government Information -- (Glen Matthews)
New virus reported (Wes Brzozowski via Dave Goldblatt via Al Stangenberger)
Virus precursor: "ANIMAL" (Mike Van Pelt)
More On Race and Ethnicity Questions... (Mike Pabrinkis)
Re: Short stories of old computer risks (Ephraim Vishniac)
Re: Notifying users of security problems (Hugh Davies)
Credit-limit handling found overly restrictive (Henry Mensch)
Bankcard authorizations (Fred McKay)
Terminals and checking the facts (Jerry Leichter)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM.
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).
----------------------------------------------------------------------
Date: Thu, 31 Mar 88 12:17:48 PST
From: cliff@Csa5.LBL.Gov (Cliff Stoll)
Subject: April Fool's warning from Usenet
Here's the warning from USENET's news.announce.important:
From: spaf@cs.purdue.EDU (Gene Spafford)
Subject: Warning: April Fools Time again (forged messages on the loose!)
Date: 1 Apr 88 00:00:00 GMT
Organization: Dept. of Computer Sciences, Purdue Univ.
Warning: April 1 is rapidly approaching, and with it comes a USENET
tradition. On April Fools day comes a series of forged, tongue-in-cheek
messages, either from non-existent sites or using the name of a Well Known
USENET person. In general, these messages are harmless and meant as a joke,
and people who respond to these messages without thinking, either by flaming
or otherwise responding, generally end up looking rather silly when the
forgery is exposed.
So, for the next couple of weeks, if you see a message that seems completely
out of line or is otherwise unusual, think twice before posting a followup
or responding to it; it's very likely a forgery.
There are a few ways of checking to see if a message is a forgery. These
aren't foolproof, but since most forgery posters want people to figure it
out, they will allow you to track down the vast majority of forgeries:
o Russian computers. For historic reasons most forged messages have
as part of their Path: a non-existent (we think!) russian
computer, either kremvax or moscvax. Other possibilities are
nsacyber or wobegon. Please note, however, that walldrug is a real
site and isn't a forgery.
o Posted dates. Almost invariably, the date of the posting is forged
to be April 1.
o Funky Message-ID. Subtle hints are often lodged into the
Message-Id, as that field is more or less an unparsed text string
and can contain random information. Common values include pi,
the phone number of the red phone in the white house, and the
name of the forger's parrot.
o subtle mispellings. Look for subtle misspellings of the host names
in the Path: field when a message is forged in the name of a Big
Name USENET person. This is done so that the person being forged
actually gets a chance to see the message and wonder when he
actually posted it.
Forged messages, of course, are not to be condoned. But they happen, and
it's important for people on the net not to over-react. They happen at this
time every year, and the forger generally gets [his/her] kick from watching the
novice users take the posting seriously and try to flame their tails off. If
we can keep a level head and not react to these postings, they'll taper off
rather quickly and we can return to the normal state of affairs: chaos.
Thanks for your support. Gene Spafford
[Especially if the forger is into forging Trojan horseshoes. PGN]
------------------------------
Date: Thu, 31 Mar 88 10:40:15 EST
From: Glen Matthews <GLEN%MCGILL3.BITNET@CORNELLC.CCS.CORNELL.EDU>
Subject: Private Access to Government Information --
Quebec Probing Information Leak
The following is from a newpaper article today in Montreal. It is reproduced
here without permission. It is an example of the possible abuses when
government files are accessed, and illustrates why system designers should
take pains to make illict access as difficult as possible.
Quebec Probing Information Leak - by Peggy Curran and Nancy Wood
Montreal Gazette, Thursday, March 31, 1988
Justice Minister Herbert Marx yseterday ordered a police investigation
into the sale of confidential information on welfare recipients by a South
Shore (of the St. Lawerence River) firm. And two other government probes
were launched in light of a Gazette story which outlined the activities of
Groupe Elite of Boucherville.
Tuesday, company official Serge Peloquin denied previous claims the
company had access to government files on welfare recipients.
However, an investigation conducted for the Gazette showed the firm was
able to come up with personal information on a welfare recipient in less
than 4 hours.
Yesterday, the Gazette learned that the Boucherville firm may also have
access to personal files on people on unemployment insurance.
In the National Assembly yesterday, Manpower Minister Pierre Paradis
promised a thorough inquiry within his department. "We believe the welfare
recipient's right to confidentiality is an unalienable right and we intend
to take the measures necessary to see it is protected", Paradis said.
Communications Minister Richard French said the Access to Information
Commission, which protects the privacy of personal documents, will conduct
its own investigation.
"We expect to know shortly whether we're dealing with a technological
problem - that is to say, whether we're not protecting adequately the data
in the computer - or whether we're dealing with an employee who isn't
respecting the ethics appropriate to his position, or whether there's some
other kind of situation", French said.
In a letter dated March 7, the company promised potential customers
the current mailing address of any person on welfare for a $10 fee. The firm
claimed to get its data "directly from the ministry".
On Tuesday, Peloquin dismissed the offer sent to collection agencies as
"a kind of false advertising", designed to attract business. He said all of
his information is available from computers at the Montreal courthouse.
Minutes earlier, he'd given a private detective hired by the Gazette a
welfare recipient's home address, parents' names and unlisted telephone
number, and the fact that he receives a disability pension.
Couthouse computers carry only the names of those who have been involved
in a civil or criminal action. Even then, listings do not include telephone
numbers, relatives' names, or welfare classifications.
[... the story goes on to recount the experience of an unidentified "victim"
who was tracked down by a finance company. He said that his address and
unlisted phone number were known to only a handful of relatives and the
Unemployment Insurance Commission ...]
Raymonde Bellerive, a public affairs officer for Employment and
Immigration Canada, said UIC has not received a formal complaint and there
are strict guidelines on the use of confidential data. But Bellerive said
the charges are worrisome and UIC will certainly investigate if the man
complains. (UIC is the Unemployment Insurance Commission.)
Michel Patenaude, an investigator for the Access to Information
Commission, said it's certainly not the first time confidential information
has leaked from a governmental or para-public agency. Leaks are apt to happen
whenever you have confidential information - and large numbers of employees
with access to it. But Patenaude said the case does raise the question of
of the way Social Insurance Numbers are widely used.
"With computers, the Social Insurance Number has become the key that
opens the door to all kinds of information. Once you've got it, it's not
that difficult to find someone who'll plug it into the system."
... the story goes on to report the reaction of groups such as the Coalition
of Welfare Recipients (churchs, food banks, etc.), and the Ligue des
Propprietaires (landlords association) ...
------------------------------
Date: Thu, 31 Mar 88 09:06:32 PST
From: forags@violet.Berkeley.EDU <Al Stangenberger>
Subject: New virus reported
Article 16275 of comp.sys.ibm.pc:
From: dave@sun.soe.clarkson.edu (Dave Goldblatt)
Newsgroups: comp.sys.ibm.pc,comp.sys.zenith.z100,comp.misc
Subject: New Virus found..
Date: 31 Mar 88 14:26:22 GMT
Reply-To: dave@sun.soe.clarkson.edu (Dave Goldblatt)
Organization: Clarkson University, Potsdam, NY
I just pulled this from my bulletin board...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FROM: Wes Brzozowski
SUBJECT: New Trojan Virus
There's a new virus program that's been seen on the West Coast, that's a
lot nastier than the COMMAND.COM virus. This one doesn't need COMMAND.COM
to carry it. It inserts itself into the boot record of diskettes, and
takes 3 unused clusters, which it then marks as "bad" in the FAT. As
such, it doesn't show up in any DOS file. Booting up from such an
infected diskette will cause all subsequent diskettes to be infected. The
original program that carries the thing is no longer needed, and in fact,
no one seems to know what the original program is, so it could be here.
I've been given a deactivated copy of the virus for study, so I know that
this piece of trash really exists. It appears to only go for diskettes
(only infects the A & B drives), not hard drives. I haven't gotten far
enough to find out what nastiness it will eventually do. It seems that it
will change the volume labels of the diskettes to "(c) Brain". The boot
record contains a message to beware of this virus, and gives an address
(in Pakistan, no less!!) to write to for protection. This seems like a
joke, but there's always an outside chance that someone is trying to do
some extortion. An infected diskette will show three bad clusters if you
run a CHKDSK on it. (So says the person who made the virus available; I
have no intention of actually activating it to check this out.)
In any case, if you happen to see this weird volume label, or start
seeing bad clusters in your diskettes, or (most likely) both, let us all
know about it. We may be able to find the source of this virus, which
would be a great service to everyone. By the way, this virus looks for
two "innoculation bytes" in two normally unused bytes in the boot record.
It presently looks like setting these to the proper value will make the
virus ignore your diskettes. I'll give more details on these after I've
gone completely through the code and am absolutely sure I know what I'm
talking about. Until then, please keep your eyes open. Take care.
Wes B.
* Origin: * N I T E W I N G * 607_687_3470 * Owego,NY * (Opus 1:260/410)
SEEN-BY: 260/10 313 314 320 322 325 330 335 345 350 360 410
------------------------------
Date: 29 Mar 88 16:23:54 PST (Tue)
From: unisv!vanpelt@unix.SRI.COM (Mike Van Pelt)
Subject: Virus precursor: "ANIMAL".
'Way back when on the Univac 1108 there was a program which had some of
the characteristics of today's viruses, though it wasn't a virus by the
strict definition. For one thing, it was perfectly harmless except for
the waste of disk space and programmer time it caused.
"ANIMAL" is a popular game program which (minus the 'virus') has been
written an rewritten for all kinds of machines. It's your basic "20
questions, guess the animal" game that remembers every animal it fails to
guess. However, while the user was playing the game, "Pervading ANIMAL"
was copying itself into every program file (very roughly equivalent to a
direcory in Unix) that the user had assigned to his session write enabled.
It was fairly intelligent about this -- it checked to make see if a
copy of ANIMAL existed in the file, and if it did, checked to see which
version was the most current. It even went so far as to put an illegal
time in the creation date of the copy, and used that to determine if the
ANIMAL program it was about to overwrite was created by ANIMAL. It would
thus avoid destroying any other program which just happened to have been
named "ANIMAL".
To avoid possible undesirable legal entanglements, (I don't THINK he'd
mind, but I don't want to take any chances) I won't name the author,
though he is a VERY big name in the PC world these days. His stated
objective was to recieve a copy of ANIMAL on a Univac system release tape.
(Of course, if he recieved it, so would everyone else in the whole
world.) Rumor has it that an operating system release was pulled at the
last minute when someone noticed ANIMAL in the system library.
The 'virus' action of the program was in a rather elegant little
subroutine called "PERVADE", which had some really classic documentation:
"Pervasive Release: A new means of distributing software:
... When someone calls you and asks you for a copy of your
program, you can tell them that in all probability they
already have it, much to their own surprise."
(Hey, maybe the GNU people would like this... :-)
There were a number of copies of ANIMAL that had been "fixed" so that
they didn't pervade. Of course, in classic Darwinian fashion these were
vastly outnumbered by the ones with intact reproductive powers. Then
with release 33 of Exec 8 the format of file item table was changed, and
ANIMAL pervaded no more, though it still played a good game of "ANIMAL".
Rumor has it that somewhere someone updated the PERVADE subroutine to
recognize the new file item format, but I haven't heard more about it
in several years. Game playing on mainframes is a dying pastime, anyway.
(We're all too busy reading NetNews :-)
Mike Van Pelt Unisys, Silicon Valley vanpelt%unisv@ubvax.ub.com
Bring back UNIVAC! ...uunet!ubvax!unisv!vanpelt
------------------------------
Date: Tue, 29 Mar 88 21:16:52 est
From: mpabrin@nswc-g.ARPA
Subject: More On Race and Ethnicity Questions...
Les Earnest (and Peter Neumann):
First, thank you for what is *really* one of the best (longest, and most
enjoyable) RISKS items I've read. If you *really, really* think about it,
there is no way to justify a RACE or ETHNICITY question, unless you accept the
notions of quotas, percentages, much et cetera, in lieu of selecting the best
qualified candidate for a position.
For several years, on various forms [I've lived in Virginia for 15 years] I've
answered RACE: HUMAN (but I must confess, intermittently). Strangely, the
answer has *never* been questioned, or at least, I've not been questioned about
it.
Before I entered the Federal Civil Service [Summer, 1963] I completed the
standard background questionnaire. To the question about membership in
organizations (by its placement, obviously derivative of the McCarthy-era
mentality) I answered ARBEITER SAENGER JUGENDCHOR, loosely the [German]
Workingmen's Singing Youth Chorus. It was based at the Labor Lyceum, a hotbed
of Socialist activity in the Thirties, and pro-German sentiment in the Forties.
My singing career was [very] short. It [began and] ended in the mid-Fifties,
but for its brief duration, I was in closely harmonious contact with many, many
holdovers from the earlier eras. Until today I never realized *why* my
background checks were *always* among the first ones completed.
Lately it is fashionable [some slug might say mandatory] in working for that
same employer to be an EEO [Equal Employment Opportunity] champion. Years ago
I was invited to join an Officers' Club. The application clearly stated that
membership was restricted to Commissioned Officers and Civil Servants at and
above a particular grade-level. I did not join, and in my declination letter
[with copy to the C.O., *always* the local EEO officer] I wrote, "...I TAKE
OFFENSE AT AN INVITATION TO JOIN AN ORGANIZATION WHICH DISCRIMINATES IN ANY
WAY, ...AND DISCRIMINATION BY RANK OR PAY GRADE IS DISCRIMINATION JUST AS
SURELY AS DISCRIMINATION BY COLOR, AGE, ETHNICITY, GENDER OR RELIGION." I
received [his] written reply which cited four references for the maintenance of
"status quo", and repeated the invitation to join. I don't think he got my
meaning, and I'm sure he *knows* I didn't get his.
More recently, after receiving literally tens of pages of flyers and electronic
mail messages of invitation to [month of February] racially and ethnically
identifiable celebrations - NO ANNUAL LEAVE REQUIRED - I invited my immediate
manager to the "Left-Handed Second Son of the Left-Handed Second Son of the
Immigrant Lithuanian Cloth Cutter Quarter-Hour of Silence" (to be held sometime
between 12:00 and 14:00 on Monday, 30-May-88). She seemed to avoid me for a
week. When I explained that it would involve hamburgers, hot dogs, beer and a
swimming pool, she began to understand.
What has any of my establishment-bashing (or Les Earnest's, - Come on! Are you
*really*?) got to do with RISKS [of Computers and other Technology In Society]?
Just this. We manufacture and implement and profit by the use of tools in our
society. We also think (and choose and love and eventually die - every one of
us, I trust). If one continuously chooses the *safe* [non-risky] path in one's
society [including *safe* answers to obviously obnoxious, albeit entrenched,
questions on forms of many organizations within the greater society], neither
the person nor the society grows. Get out there and challenge the bigots! Both
you and the society will grow. Oh, but do it reasonably. Finally, the
tie-in... The same habit of questioning, analysis, refusal to accept [a
less-than-good] existing tehnology, and suggestion of a better way, is usually
rewarded by a fair-minded manager [both within and without the Government].
I've often wondered *why* the same person who will not accept or tolerate
shoddy work or thinking on the job, will choose to ignore or tolerate or accept
or embrace any shoddy societal norm.
Mike Pabrinkis (K33) mpabrin@nswc-g.arpa
Naval Surface Warfare Center (703)663-7529
Dahlgren, VA 22448 (AV)249-7529
DISCLAIMER: Yes, the opinions are *only* mine. You are invited to
ignore, tolerate, accept or embrace [or even rebut].
and POSTSCRIPTS: If you'd like to know more details about the 30-May-88
"...Quarter-Hour", contact me directly [less-RISKy].
A tender apology for punning Les's name. He *really* is Les Earnest.
Now, go back and *analytically* re-read the subject-line. Thank you.
------------------------------
Date: Thu, 31 Mar 88 14:46:34 EST
From: ephraim@Think.COM
Subject: Re: Short stories of old computer risks (Les Earnest)
In RISKS 6:50 Les Earnest writes of his trials and amusement with a
system that tried to classify him:
> The incidents described span a period of twenty years ending 25
> years ago, but I think they are still amusingly relevant.
His recollections of institutional racism reminded me of an anecdote
from my father, and that in turn suggested a forward-looking moral to
both stories. First, the story:
In about 1955, my father was stopped for running a stop sign. (He
didn't see it, honestly.) The policeman asked my father for various
information, including his nationality. "I'm American." he replied
with a thick accent. The officer was unconvinced.
"But where are you *from*?"
"Well, I was born in Berlin."
"German, then."
"I was never a German citizen. I was Latvian. But now I'm American."
"Latvia? Where's that?"
"It's not there anymore. It's part of the Soviet Union."
"So you're Russian."
"No, my father was Russian, not me. My mother was Latvian. We're all
American now."
The officer called the station for instructions. He had a lively
discussion with the desk sergeant, during which my father overheard
him exclaim that, "You're not American unless you're six ways a
bastard!" Eventually they concluded that, given the presence of a
valid Connecticut driver's license, nationality wasn't really that
important on a traffic ticket.
Second, the moral:
It's difficult now to imagine the social climate of the 1950's in
which these incidents occurred. It's sometimes claimed that some
system, power, or technology won't be abused because society - social
pressure, morals, or current law - prevent it. But next year things
will be different, and in thirty years the social climate of today
will be almost impossible to recall. That's why it's important, in
forums such as this Risks Digest, to consider the conceivable risks
and not only the present ones.
Ephraim Vishniac ephraim@think.com
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214
------------------------------
Date: 31 Mar 88 01:25:29 PST (Thursday)
From: "hugh_davies.WGC1RX"@Xerox.COM
Subject: Re: Notifying users of security problems
In RISKS 6.50, Andy Goldstein (goldstein%star.DEC@decwrl.dec.com) states..
"Sending out notice of the presence of a bug without a correction or
workaround is of course even more irresponsible."
When I first saw this I couldn't believe what I was reading. Well, I've reread
it several times, and it still says the same thing. I only hope that Andy was
joking, or that I have grasped the meaning wrongly, because what I think that
it means is that I can get bitten by a bug that someone knows about, but
hasn't told me because he doesn't have a fix or workaround.
Surely, just knowing about a bug is enough to help avoid it causing problems?
If I know that doing a particular operation causes problems, I will avoid
doing that operation, and that is a workaround in itself.
Also, knowing that a bug exists in a particular area will save me manhours, and
therefore money, investigating a problem which is already known.
Please, Andy, tell me I've got it wrong!
Hugh Davies.
------------------------------
Date: Wed, 30 Mar 88 22:44:09 EST
From: henry@GARP.MIT.EDU (Henry Mensch)
To: Brown@GODZILLA.SCH.SYMBOLICS.COM
Subject: Credit-limit handling found overly restrictive (RISKS-6.50)
Date: Tue, 29 Mar 88 13:48 PST
From: Wm Brown III <Brown@GODZILLA.SCH.Symbolics.COM>
Look at the number of characters in an authorization code; it is far
too small to reflect the number of authorizations issued ...
When I worked at Chase Manhattan in New York authorization codes (for
check encashment, not credit card authorization, but I suspect they
work in similar ways) were a function of the dollar amount of the
item, the day of the week and the date. Other institutions may have
other (perhaps proprietary) ways to compute an authorization code.
The functions used probably have no relation to the number of
transactions authorized in a single business day.
# Henry Mensch / <henry@garp.mit.edu> / E40-379 MIT, Cambridge, MA
# {ames,cca,rochester,harvard,mit-eddie}!garp!henry
------------------------------
Date: Thu, 31 Mar 88 18:38 EST
From: FMCKAY%HAMPVMS.BITNET@MITVMA.MIT.EDU
Subject: Bankcard authorizations
Many years ago I was asked to set up a system to monitor phone traffic for a
regional authorization center in Florida. I was told by someone there that
the authorization code was a checksum on such things as card number, merchant
number, and AMOUNT. It seems to me that if this is the case, an authorization
for an estimated amount would make the code formula tilt if the charge was
later challenged.
I currently accept MC/Visa in my business and once received an authorization
for a charge that the bank returned as invalid. Since the card number was
read to me over the phone, I assume something got garbled in the process.
However, how did the authorization go through?
I would be curious to hear of similar experiences but I make no representation
as to the accuracy of the formula information considering the age and source.
Fred McKay ---- FMCKAY@HAMPVMS.BITNET
------------------------------
Date: Thu, 31 Mar 88 13:46 EST
From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)"
Subject: Terminals and checking the facts
In RISKS 6.51, A.E. Mossberg takes me to task for not considering the security
of block mode in VT220's, and proceeds to outline a way to use block mode to
cause a VT220 to send an arbitrary set of commands back to the host.
The problem with the scenario is that it has nothing to do with reality.
Neither the VT220, nor any of the VT200 series, has any block mode instruc-
tions! Mr. Mossberg claims to have "looked in the VT220 manuals" to construct
his scenario; clearly he didn't look very closely.
Ignoring ancient history like the VT62 and speciality products, the only DEC
terminals with block mode are VT131 and VT132 (both now two to two and a half
generations old and obsolete; I won't discuss them further) and the VT330 and
VT340. (The VT320 MIGHT have block mode; I doubt it but don't have a manual
to check.)
There are two ways to configure block mode on a VT3xx. Normally, sending from
the screen is initiated from the keyboard by the user hitting the Enter key.
This mode provides no direct opportunity for a host to read back stuff from
the screen "on its own", though of course it is not risk-free - the user may
be too trusting and hit Enter when there is stuff on the screen that he didn't
put there and doesn't want sent! The other mode is also nominally controlled
from the terminal: When the user hits Enter, the terminal sends a "request to
send screen" message; the host responds with a "send screen now" message. The
manual doesn't say whether a "send screen now" message received when the ter-
minal hasn't sent a "request" will be honored. If it is, there's a potential
hole; if it isn't - certainly an option that's easy to implement - the user
remains in control.
All that said, having block mode is INHERENTLY somewhat riskier than not
having it, though the risk can be made quite small by proper design.* This
fact was recognized by the designers of the VT3xx: There is a SETUP option
that disables block mode completely. The host can then send "Enter block
mode" sequences as much as it likes, with no effect.
-- Jerry
* The way to make a truely secure block mode terminal is to realize that the
source of the problem is the ability of a malicious program to cause input
indistinguishable from user typein to get sent down the line. If block mode
transmissions were always wrapped in a recognizable sequence - for example,
if they were always within a distinctive DCS - the host could filter out
block transmissions received in places where none were expected. Of course,
ALL software on the system that could be vulnerable to such replayed data
would have to filter it. Fortunately, if you look at the way user interfaces
work, you'll see that typically making the shell-equivalent "careful" is
enough.
Why isn't this done? Mainly, I suppose, because block-mode terminals are
intended for use with applications that completely control the terminal with
trusted software. Programmers don't use block-mode terminals; data entry
people do. So the issue isn't of such great import. The VT3xx, which is
intended to serve multiple markets, takes just the right approach: Block mode
is there if you want it, and you can disable it otherwise.
------------------------------
End of RISKS-FORUM Digest
************************
-------