Text File

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 ************************