Subject: RISKS DIGEST 16.67 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 23 December 1994 Volume 16 : Issue 67 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** SEASONS' GREETINGS from the PEripaTEtic Risks moderator. ***** ***** NOTE, THE SRI RISKS ARCHIVE SOURCE has moved to unix.sri.com. ***** ***** See last item for further information, disclaimers, etc. ***** Contents: Software glitch snares Social Security Administration (Mike Manos) Cancelbot Derails Online Promo (WSJ via Edupage) Ben & Jerry's expects first loss (Arthur D. Flatau) Proliferation of Cockpit Warning Signals (David Walter) Year 2000 date problems already happening now (Elana) Re: Prevention of Oral Hacking (Brad G. Parks) Re: Pentium FDIV problem - so what's new? (Mark Brader) Intelligent Commentator on McNeil-Lehrer (D.P. Schneider) Financial Payment Systems (Jeff Stapleton) Possible solution to the (electronic) meme problem (Bob Mehlman) Advertising on the Net (Mich Kabay) Risk Takers Among Management (Tom Kaiser) Re: Koppel et al. (Peter da Silva) Re: Microsoft and the Catholic Church (John Stevenson) EDUPAGE on the WWW (Timothy Hunt) Public CM WAIS Server to end operation (WAIS Admin) Call for Papers and Panels: National Information Systems Security Conf. (Jack Holleran) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 21 Dec 1994 14:49:13 EST From: Mike Manos Subject: Software glitch snares the Social Security Administration [from Federal Computer Week, 21 Nov 1994] The Social Security Administration has uncovered a software coding error that over the years nickeled and dimed Social Security recipients out of $478.5 million. The problem occurred in 1978, when SSA wrote new code because employers began reporting earnings annually rather than quarterly. The software program, with its 76 sets of variables, had a few holes in it. Over 16 years, about 426,000 people did not receive appropriate payment increases. ------------------------------ Date: Tue, 20 Dec 1994 18:15:26 -0500 From: info@ivory.educom.edu (Edupage) Subject: Cancelbot Derails Online Promo (WSJ via Edupage 12/20/94) CANCELBOT DERAILS ONLINE PROMO Messages promoting "Netchat," a new book by Michael Wolff, have been unceremoniously wiped out by someone calling him/herself "Cancelmoose." The vigilante, who used a program called a cancelbot, worked through a computer in Finland that enables a mail sender to remain anonymous, and claims to have performed similar services more than a dozen times in the past. (*Wall Street Journal*, 20 Dec 1994, p. B7) ------------------------------ Date: Wed, 21 Dec 94 08:52:14 CST From: flatau@cli.com (Arthur D. Flatau) Subject: Ben & Jerry's expects first loss According to an article (page F2) in the Tuesday December 20, 1994 issue of the Austin American Statesman (from the Associated Press) Ben & Jerry's Homemade Inc. is going to report its first quarterly loss since it went public. Quoting some of the relevant to risks part of the article: Adding to the bad news, the company said Monday that recurring problems in a comuterized handling system will force it to delay opening a new, more efficient manufacturing plant in St. Albans, Vt. until the middle of next year. [...] "While out earnings have been negatively impacted in 1994 by the inefficiencies in the company's production planning, purchasing and inventory management systems ... the anticipated loss in the current quarter is due primarily to lower than expected sales lever," [Ben & Jerry's President Chuck] Lacy said in a written statement. [...] At the new St. Alban's plant, a computerized system that was supposed to automate handling of ice cream after it has been packed into pints has software problems, forcing the company to substitute a more conventional system. That likely will require installation of different equipment and more employees for handling, although the company said it will still be more efficient than current manufacturing. The St. Albans plant is designed to consolidate all of Ben & Jerry's manufacturing in Vermont again. The company hires Edy's [a major competitor] of Fort Wayne, Ind. to make about 37 percent of its ice cream, [Ben & Jerry's spokesman Rob] Michalak said. Art flatau@cli.com Computational Logic, Inc. Austin, Texas ------------------------------ Date: Wed, 21 Dec 94 13:54:23 GMT From: D.Walter@sheffield.ac.uk Subject: Proliferation of Cockpit Warning Signals The avionics thread seems to have gone quiet, perhaps because none of the several recent airliner crashes has involved an A320 aircraft. Here is an account of an incident I came across recently which highlights the problem of proliferation of warning signals in complex human-machine interfaces. The incident involved a Continental Airlines 727 which came perilously close to landing gear-up at Chicago O'Hare about a year ago. Initial investigation indicated that the crew had become distracted from their landing check-list by TCAS (Traffic Collision Avoidance System) warnings which sounded repeatedly as they flew through the busy airspace around O'Hare. The 727's gear warning did not trigger because the flap setting was 25 degrees instead of the usual 27.5 (in order to maintain speed on approach as requested by air traffic control). A ground proximity warning did sound at 500 ft, but lack of gear is only one of a number of possible causes for this warning. A taxiing American Airlines pilot saw the 727 on short final with no gear. The tower radio transcript makes hair-raising reading: American: "Tower, Continental's got no gear!" Tower: "Who's got no gear?" American: "Continental, just about ready to touch down on two-seven left" The ground controller shouted to his colleague who was controlling Continental's approach, who warned: "Go around, go around Continental. No gear!" The 727 succeeded in executing a go-around, but not before scraping the rear third of the fuselage on the runway. It landed normally out of the second approach. David Walter ------------------------------ Date: Fri, 23 Dec 1994 05:48:33 GMT From: elana@netcom.com (Elana who?) Subject: Year 2000 date problems already happening now A few months ago, there was an excellent article in RISKS about the problems of the year date rolling from xx/xx/99 to xx/xx/00 and how it could affect computer systems. Today I mentioned the article in passing to a rep at my local bank as I was making a routine deposit. She said: "It's happening already." Apparently there is a problem with some of the credit cards they have been issuing to their customers. The expiration date on them is the year 2000, and for some tech reason she could not explain, two major stores here in town refuse to take them "because that weird date messes up their computers." I regret that I cannot offer more info than this, but it is serious food for thought... -Elana [See the latest American Scientist, Jan-Feb 1995, which has a very nice article by Brian Hayes, spanning the entire subject. (Much of it is drawn from the RISKS Archives.) PGN] ------------------------------ Date: Thu, 22 Dec 94 11:21 CST From: bparks@intcorp.com (Brad G. Parks) Subject: Re: Prevention of Oral Hacking I am a big fan of Voice Recognition Technology, however trite and useless people may say it is. And one thing that people have failed to mention so far that there are ways to prevent/discourage oral hacking (at least with Macintosh's general program). With the Mac program there is an option that allows the user to name the computer something other than "Computer." There is another option for setting an "Attention Key" to basically give the program earplugs until that key is pressed again. There is also a voice recognizing option that sets how precise your language must be. It is doubtful, at least to me, that somebody running around the office yelling "Computer, Restart, Yes" would restart my Mac, whose name is Alfred, has the precision level set rather high, and also has the voice recognition asleep until i press Keypad-0. Brad G. Parks (bparks@intcorp.com) [Software Engineer, O-Programmer] Introl Corporation (612)-631-7810 2675 Patton Rd. St.Paul, MN 55113 [Ah, now we know! And we can record your normal voice and replay it. PGN] ------------------------------ Date: Wed, 21 Dec 1994 14:03:47 -0500 From: msb@sq.com Subject: Re: Pentium FDIV problem - so what's new? (Peterson, Risks-16.66) It occurs to me that the English vocabulary might be related to why people have reacted so strongly to the existence of this bug -- which, let's face it, is not all that devastating *relative to other bugs*. The term "computer" suggests that computation is the most important and fundamental thing that the machine does, and because of this, any bug directly related to computation is seen as more serious than others. In French the machine is called an "ordinateur", which is related to our word "ordinal" and conveys connotations of *organizing* data. What we mostly call computer science, they call "informatique" -- the study of information. And if you think about what computers are used for today, you will see that these terms are at least as fitting as the English ones. In English when we really mean that computation is the important part of the work, we use terms like "numerical" in addition to "computing". Would English speakers have reacted equally strongly to a -- no pun intended -- comparable bug in the instructions for comparing and branching? I think they would not. (No, you don't need to tell me that a large part of the reaction in this case was to Intel's reaction, not to the original problem.) Mark Brader msb@sq.com SoftQuad Inc., Toronto ------------------------------ Date: Thu, 22 Dec 94 16:34:00 PST From: d_schneider@emulex.com Subject: Intelligent Commentator on McNeil-Lehrer A recent McNeil-Lehrer report (I'm pretty sure it was Tuesday night's -- 12/20/1994) had an intelligent commentator as an interviewee on the Pentium situation. I agree with his comments about the Pentium (that the problem was probably more severe than Intel admitted and less severe than IBM trumpetted), but the reason I'm pointing this interview out is because Robin McNeil asked something to the effect, "So the issue is also that we shouldn't trust an answer just because the computer gave it to us?" The interviewee answered that this was just so, and that we should keep asking for and demanding proof that the computer is giving good answers. There were also what I thought were intelligent comments on the difficulty of thoroughly testing such complex parts, and that testing had to involve strategies to maximize the confidence obtained. I hope that one of your other submitters has given (or will give) the identity of the interviewee, and some exact quotes. I was impressed by his grasp of the big picture, and that he managed to convey it to the interviewer, too. (I think the choice of interviewer helped, but even intelligent interviewers can't be prepared to understand all issues, and McN-L tend to have more news on political and economic issues than on technical issues). Hope you caught the interview, too! /dps ------------------------------ Date: Thu, 22 Dec 1994 10:56:25 -0600 From: mc!Jeff_Stapleton@mhs.attmail.com Subject: Financial Payment Systems In regards to RISKS-16.64 here are some thoughts and concerns about financial payments on the World Wide Web, CommerceNet, the Internet, and electronic media in general: Debit card payments today require an additional piece of authenticating data - the Personnel Identification Number or PIN. There are ISO (9564) and ANSI (X9.8) standards which tell us how to securely formulate a PIN block and encrypt it using the Data Encryption Algorithm or DEA (X3.92). Credit card payments may soon also require the PIN. However, we have no standards today telling us how to encrypt PINs using public key algorithms. True, the advent of the smartcard may eliminate the transmission of PINs, but not for a while yet (years?). Speaking of public key cryptosystems, there ARE existing ISO and ANSI standards available today: ISO-CD 11568 parts 4 and 5 just completed the public ballot process. ANSI X9.30 part 1 - The Digital Signature Algorithm (DSA) ANSI X9.30 part 2 - The Secure Hash Algorithm (SHA) ANSI X9.30 part 3 - Certificate Management for the DSA is completing its public ballot process. However, due to the legal problems between Cylink Corporation and RSA Data Security on fair licensing agreements for the RSA patents, the matching set of ANSI standards (X9.31 parts 1, 2, and 3) for RSA may be put on hold by the Accredited Standards Committee (ASC) X9 - for further details, call: X9 secretariat, American Bankers Association (ABA), 202-663-5284 X9F chairman, Marty Ferris, 202-622-1110 X9F1 chairman, Blake Greenlee, 203-762-8580 Although the standard addresses the DSA, X9.30-3 Certificate Management is rather generic and deals with the roles and responsibilities of the asymmetric key pair owners, the certificate authority(s), and the public key users. Interesting stuff and can (and should be) used for implementing any public key cryptosystem. Copies can be purchased from the ABA (plug). Jeff J. Stapleton - MasterCard International ------------------------------ Date: Wed, 21 Dec 1994 18:43:08 PST From: rmehlman%grumpy.decnet@UCLASP.IGPP.UCLA.EDU Subject: Possible solution to the (electronic) meme problem Keith Henson (RISKS 14.63) points out that computer viruses and human fads fit Richard Dawkins' concept of a meme, adding What computers and fast communications have done is to radically change the replication constants for memes, and to make unworkable the controls society has tried to put on such things. In "Mind Viruses" (American Scientist, Jan-Feb 1995, p.26), Michael Szpir discusses 'human information parasites', such as the St. Jude 1 chain letter, likened to memes by Dawkins and Oliver Goodenough (Nature, Sept 1, 1994). Some years ago, I received an electronic chain letter, complete with lengthy sequential history of previous senders. These letters differ from the old- fashioned kind -- they always have return addresses. It occurred to me that the appropriate response was to SEND IT BACK, and encourage the sender and all others to do likewise, hoping an avalanche of returned mail would eventually swamp the original sender, if it didn't bring the network to its knees. No such luck. I actually tried it, forwarding the letter back to the sender with subject LET'S SEND IT BACK. Unfortunately, he returned it immediately, longer by two headers, with subject THAT'S NOT FAIR...IT'S GOT TO BE 5 OTHER PEOPLE. I did not repeat the experiment, though I tried unsuccessfully to get others to do so. Still, I wonder, next time a chain letter or other intentional meme spreads through the Internet, if everyone returned their copies to the sender ... Bob Mehlman, UCLA/IGPP ------------------------------ Date: 22 Dec 94 14:25:04 EST From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Advertising on the Net In the 05 Dec 1994 issue of _Network World_ on p. 41, "John Doe" recounts his tale of woe after advertising on the Internet ("Ad leads to a nightmare on Cyber-Street). In brief, his main points are * Placed ads in several USENET groups. * Swamped with email abuse and flames in the groups as a result. * Someone posted his 800- number in alt.sex groups as a phone-sex #. * Switchboard swamped with requests for phone sex; operators horrified. * One switchboard op quit because of what callers were saying. * All 800- calls switched to the originator of the advertising as punishment. * Impractical to cancel 800- service because of special letter combinations. Moral: don't advertise on the Net. <> M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn ------------------------------ Date: Thu, 22 Dec 1994 23:22:43 -0500 From: Tomkaiser@aol.com (Tom Kaiser) Subject: Risk Takers Among Management Subject: Upper Managements View of Information Security(Infoworld 12/19/94) The following extract from _INFOWORLD_ 12/19/94 demonstrates some of the risks inherent in human management. (I read this shortly before reading RISKS 16.66 and the posts calling for papers and serious work in all areas of network and computer security). 42% of senior management at U.S. companies consider information security to be only "somewhat important" or "not important," according to a survey by Ernst and Young LLP, with 15% of companies devoting no full time resources to security. This though even more than half the respondents reported information-related losses. Also , among respondents who said they were running "mission-critical applications" on their LAN's, half reported that security was unsatisfactory. What will it take to make security a priority in industry? The Stealth bomber blueprint on place mats in Pizza Hut? (end copy) We can only hope that some of the recent antics and activities on the network cause these top managers to focus some their energies, and resources on the protection of their (our?) data. Analysis of all probable problems and or threats should precede implementation of any changes to or introduction any systems. I think most readers of RISKS would enjoy reading the entire poll and possibly having helped in phrasing some of those obscure questions, and "open to interpretation answers." Thomas Kaiser Tomkaiser@aol.com ------------------------------ Date: Thu, 22 Dec 1994 17:51:54 -0600 From: peter@nmti.com (Peter da Silva) Subject: Re: Koppel et al. (RISKS-16.66) I seem to recall someone with the name of "Hughes" being forced to change the name of his hotel because Howard Hughes objected. Be glad your name doesn't match someone like that. ------------------------------ Date: Fri, 23 Dec 1994 22:53:37 +0000 From: John Stevenson Subject: Re: Microsoft and the Catholic Church (RISKS-16.66) >Microsoft has no plans to acquire Catholic Church (from EDUPAGE) Surely the big RISK here is that the world is infested with people who lack even a trace of a sense of humour. Hoax? I believe 'Microsoft to acquire Catholic Church' was what we writers call 'a joke'. John Stevenson john@mtnbike.demon.co.uk mbuk@cix.compulink.co.uk [I would call it a *parody*. RISKS readers seem to be a cut above the average in terms of not being fooled so easily, especially by such obvious parodies. But remember there are a lot of nontech folks out there with very bad spoof-suspicion thresholds. Even the most *obvious* humor sometimes gets taken seriously. Remember what happened to Piet Beertema's Chernenko hoax! Many people took it very seriously. Some might have even attempted to spoof the spoofer by pretending to take it seriously. At any rate, best wishes for a happy new year, with its own collection of good humor. PGN] ------------------------------ Date: Wed, 21 Dec 94 14:55:07 +0000 From: "Timothy Hunt [Assistant Unix Systems Manager]" Subject: EDUPAGE on the WWW Noticing the article that made reference to EDUPAGE [Microsoft has no plans to acquire Catholic Church], RISKS readers may be interested to know that EDUPAGE is available via the Web, with URL : http://www.ee.surrey.ac.uk/edupage Timothy J. Hunt, Joint Dept. of Physics, The Inst. of Cancer Research, Downs Road, Sutton, Surrey England SM2 5PT Timothy@icr.ac.uk +44(0)181 642 6011 x3312 ------------------------------ Date: Thu, 22 Dec 94 11:36:41 EST From: waisadm@cmns.think.com (Wais Administrator account) Subject: Public CM WAIS Server to end operation The Public CM WAIS Server, which has provided a searchable database of past RISKS traffic as risks-digest.src, will cease operation on 27 December 1994. Please update the "Info on RISKS" item and inform your readers of the change. [Here we come a-WAIS-ailing! And many thanks for your past serv-ice! PGN] ------------------------------ Date: Thu, 22 Dec 94 20:13 EST From: Jack Holleran Subject: Call for Papers and Panels: National Information Systems Security CALL FOR PAPERS AND PANELS 18TH NATIONAL INFORMATION SYSTEMS SECURITY CONFERENCE (formerly the National Computer Security Conference) Co-sponsored by the National Computer Security Center and the National Institute of Standards and Technology Baltimore Convention Center, Baltimore MD October 10-13, 1995 The National Information Systems Security Conference audience represents a broad range of information security interests spanning government, industry, commercial, and academic communities. Papers and panel discussions typically cover: ( research and development for secure products and systems presenting the latest thinking and directions; ( practical solutions for real-world information security concerns; ( implementation, accreditation, and operation of secure systems in a real-world environment; ( evaluation of products, systems, and solutions against trust criteria; ( security issues dealing with rapidly changing information technologies; ( network security issues and solutions; ( management activities to promote security in IT systems including security planning, risk management, and awareness and training; ( international harmonization of security criteria and evaluation; ( social and legal issues such as privacy, ethics, investigations, and enforcement; ( tutorials on security basics and advanced issues; and ( highlights from other security forums. We invite the submission of papers and proposals for panel discussions in any of the above areas as well as other topics related to IT system security. We especially encourage student papers written by individuals in degree programs. The student should not have been previously published, and the paper shall be endorsed by an academic advisor. BY MARCH 1, 1995: Eight (8) copies of your draft should arrive at the following address. See instruction on reverse side regarding the format of your submission and accompanying information required. National Information Systems Security Conference Attn: Conference Secretary, APS XI National Computer Security Center Fort George G. Meade, MD 20755-6000 BY JUNE 1, 1995: Authors and Panel chairs selected to participate in the Conference will be notified and advised when final papers and panel statements are due. For additional information on submissions, please call (410) 850-0272 or send Internet messages to NISS_Conference@DOCKMASTER.NCSC.MIL. For other information about the National Information Systems Security Conference, please call (301) 975-2775. PREPARATION OF CONFERENCE SUBMISSIONS Cover Sheet: Type of submission (paper, panel, tutorial) Title or Topic Abstract (not to exceed 250 words) Author(s) Organizational Affiliation Phone numbers (voice and fax, if available) Internet address, if available Point of Contact, if more than one author Submissions related to work under U.S. Government sponsorship must also include the following information: U.S. Government Program Sponsor or Procuring Element Contract Number (if applicable) U.S. Government Publication Release Authority Classified material or topics must NOT be submitted. Draft Papers: 10 page maximum, including figures and references. Include title, abstract, and keywords on first page. No more than 12 characters/inch and 6 inches/line. One-inch margins all around. Since the paper referee process will be anonymous, names and affiliations of authors should appear only on the separate cover sheet. All submissions are treated as proprietary information belonging to the authors. Release for Publication and Copyright: Authors are responsible for obtaining government or corporate releases for publication. Written release will be required for all papers to be published. Papers developed as part of official U.S. Government duties may not be subject to copyright. Papers that are subject to copyright must be accompanied by written assignment for multi-media publication to the National Information Systems Security Conference Committee. PANEL PROPOSALS: ( Panels are limited to 90 minutes, including time for prepared remarks, discussion, and audience interaction. ( Proposals are not to exceed two pages but should summarize the topic, issues, viewpoints and questions that will be addressed by the panel. ( Proposals are to include the names of panelists, panel chair, and affiliation of each participant. ( Each panel is limited to *five (5)* persons, including panel chair and four (4) panelists. ( Panels will be selected by the Conference Committee. Panel chairs and panelists will be expected to provide written statements for inclusion in the Conference Proceedings. ( Panel proposals *must be* received by March 1, 1995. ------------------------------ Date: 23 December 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (soon to be automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. CURRENT ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 15, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. Risks can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.67 ************************