Subject: RISKS DIGEST 17.19 REPLY-TO: risks@csl.sri.com RISKS-LIST: Risks-Forum Digest Monday 19 June 1995 Volume 17 : Issue 19 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Summer Slowdown for RISKS (PGN) Bank computer develops costly crush on Fiona (Peter Ilieve) The Royal Majesty (Bob Frankston) For DOS/Windows users: Trojan Alert- PKZ300B.EXE (Patrick Weeks via Fred Gilham) Re: The New York subway crash (Mark Stalzer) Re: 59-Story Crisis: The Risks of Unions (Chuck Weinstock) Internet gambling (Andrew Koenig) The media & risks (Justin Wells) CFP: ISOC Symposium on Network & Distributed System Security (Clifford Neuman) Re: Multo ante natus eram (Mike Alexander, Mike Crawford) Prodigy paranoid reaches Tasmania? (Richard Murnane) Re: not caring about Prodigy (Jim Hill, Bob Morrell, Jim Hill) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 19 Jun 95 08:01:17 PDT From: "Peter G. Neumann" Subject: Summer Slowdown for RISKS RISKS will be more or less off the air from now until July 24. I will probably not be able to answer many of your queries and requests during that period even when I am on-line. Continuations of recent ongoing discussions are likely to cease as of this issue. However, please send in all interesting NEW items that you encounter. For our 10th anniversary RISKS issue on 1 August 1995, I would be very happy if a few of you would submit (by 24 July) concise and well-reasoned think-pieces on what we might have learned in the past 10 years, with respect to some aspect of the RISKS experience. Have things improved? Or are we collectively treading water -- or being washed out to sea? What is missing? Are the real problems technological or otherwise? (The best reflective contributions might even wind up as Inside Risks columns in the CACM!) I hope you all have a pleasant summer. PGN ------------------------------ Date: Sun, 18 Jun 95 20:51:25 BST From: peter@aldie.co.uk (Peter Ilieve) Subject: Bank computer develops costly crush on Fiona That was the headline on a piece in *The Times* (London) on 15 June 1995 about a Barclays Bank computer system that deals with loans and mortgages to bank staff. It was running a new accounting system, and it refused to generate monthly repayments for more than 100 staff named Fiona. Nobody else was affected, including a Ffyona. Numerous Fionas were sufficiently honest to contact the bank and ask why their repayments hadn't been deducted. It isn't clear how long the lucky Fionas would have had their repayment holidays if some of them hadn't owned up. The bank is adamant no hacking was involved. A spokeswoman blamed `a blip' and added, `Our systems people say that they knew how to solve the problem even if they could not explain what precisely had caused it.' Peter Ilieve peter@aldie.co.uk ------------------------------ Date: Mon, 19 Jun 1995 14:25 -0400 From: Bob_Frankston@frankston.com Subject: The Royal Majesty The Royal Majesty is the cruise ship that ran aground off Nantucket. There is a good article in *The Boston Globe* 19 Jun 1995 by David L Chandler entitled "Embarrassing lessons for navigators". It is a good "risks style" article that covers various issues including the question of whether the GPS system indeed failed and was 17 miles off. It discusses issues of the user interface -- is navigation information presented in such a way as to actually be usable during hectic periods? It brings up question of whether it is safe to turn off Loran, the Valdez accident, and other pertinent issues. Nothing particularly new for Risks readers, but it is worthwhile to note reasonable articles in the newspapers. ------------------------------ Date: Mon, 19 Jun 1995 10:34:05 -0700 From: Fred Gilham Subject: For DOS/Windows users: Trojan Alert- PKZ300B.EXE ------- Forwarded Message *** Subject: TROJAN ALERT: PKZ300B.EXE / PKZ300B.ZIP *** **************************** Important Notice ************************* Some joker out there is distributing a file called PKZ300B.EXE and PKZ300B.ZIP. This is NOT a version of PKZIP and will try to erase your harddrive if you use it. The most recent version is 2.04G. Please tell all your friends and favorite BBS stops about this hack. Thank You. Patrick Weeks Product Support PKWARE, Inc. *********************************************************************** ------------------------------ Date: Fri, 16 Jun 95 08:30:38 EDT From: mstalzer@etsd.ml.com (Mark Stalzer) Subject: Re: The New York subway crash (PGN, RISKS-17.17) As reported in the June 16 New York Times, further investigation of the 5 Jun 1995 NY subway crash (which killed the motorman and injured 54 people) indicates the distance between signals is shorter than the stopping distance of a modern train. Speculation right after the accident had focused on a possible emergency brake failure. However, even with the brake engaged, tests showed it takes approximately 360ft for the train to stop. Unfortunately, the rear of the forward train was only 288ft from the signal. It now appears that the motorman ran the red signal, which tripped the emergency brake and slowed the train from about 32mph (the maximum speed after climbing the hill leading to the crash area) to 14-18mph at the time of impact. The signal spacing was set in 1918 when trains were shorter, lighter, and slower than modern trains. The Transit Authority has been upgrading the trains without upgrading the control system. A familiar RISK. The immediate response has been to limit speeds on the section of track where the accident occurred. When a TA official was asked if speeds will be reduced in other areas, the official said "we don't know where the potential trouble spots are." I guess we're just going to wait for more accidents to find the areas that need fixing. Another familiar RISK. Mark Stalzer, mas@acm.org ------------------------------ Date: Mon, 12 Jun 95 12:10:30 -0400 From: Chuck Weinstock Subject: Re: 59-Story Crisis: The Risks of Unions One of the risks that continues to haunt me from that article (and apparently others as well since my mother mentioned it to me when we discussed the article) is this: (The people in charge of repairs to the building had installed strain gauges connected by wire to readouts in the main office.) One time, the readings went off the chart, then stopped. This provoked more bafflement than fear, since it seemed unlikely that a hurricane raging on Lexington and Fifty-third Street would go otherwise unnoticed at Forty-sixth and Park. The cause proved to be straightforward enough: When the instrumentation experts from California installed their strain gauges, they had neglected to hire union electricians. `Someone heard about it,' LeMessurier [the building designer] says, `went up there in the middle of the night, and snipped all the wires.' Chuck Weinstock ------------------------------ Date: Thu, 15 Jun 95 20:01:01 EDT From: ark@research.att.com Subject: Internet gambling I remember once reading a paper with a synopsis something like this: This paper is in two parts. In Part 1, we prove that it is impossible to play a fair game of telephone poker. In Part 2, we give an algorithm for playing a fair game of telephone poker. The apparent paradox, of course, was that the algorithm in Part 2 was actually unfair with a probability that could be made as small as desired by making the crypto keys long enough. I wish I remember the title or author of the paper. Anyway, such things leave me with the distinct impression that Internet gambling is no less feasible than any other kind of electronic commerce. Andrew Koenig ark@research.att.com [For the short-term future, we will see many small-scale efforts such as this one, whether or not they are soundly based. In the long-term, we still need a secure infrastructure and trusted servers and trustworthy individuals and more laws (and lawyers) to give it a real semblance of "fair". (We might refer to this as "secure infostructure".) PGN] ------------------------------ Date: Mon, 19 Jun 1995 01:23:24 -0400 From: rjwells@undergrad.math.uwaterloo.ca (justin wells) Subject: The media & risks It occurred to me that the stories in comp.risks are often sensationalistic enough to warrant widespread media coverage. In fact, a good chunk of stuff posted here is drawn from the media, with commentary added. One risk commonly mentioned here is that "the public" or "the media" haven't got enough understanding of computer risks, and that we're all going to suffer as a result -- recently there's been discussion of lawyers who don't understand computers, etc. Well -- Has anyone tried convincing some television producers to add a computer risk segment to their news programs? There's easily enough material that's interesting enough that's already part of their program -- to make it a proper segment all that would be required is the addition of a brief editorial highlighting for the public the general nature of the particular risk. I think it would be interesting enough to sell (but then as a regular reader of comp.risks I'm biased :) I don't have the background or the experience or the connections or anything else to try and make something like this actually happen, but I'm sure that somewhere out there in RISKS land, someone does... Imagine the benefits of having computer risks dealt with sensibly on CNN. Here in Canada the late night news just ran an extensive segment on the risks of cellular phones and radios interacting with medical equipment, so it's not like the media is opposed to the idea. What with all the hype about the Internet these days, I think there's a major window of opportunity... Justin rjwells@undergrad.math.uwaterloo.ca ------------------------------ Date: Sun, 18 Jun 1995 06:49:34 -0700 From: Clifford Neuman Subject: CFP: ISOC Symposium on Network & Distributed System Security CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security February 22-23, 1996 San Diego Princess Resort, San Diego, California GOAL: The symposium will bring together people who are building hardware and software to provide network and distributed system security services. The symposium is intended for those interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. Symposium proceedings will be published by the IEEE Computer Society Press. Topics for the symposium include, but are not limited to, the following: * Design and implementation of communication security services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Design and implementation of security mechanisms, services, and APIs to support communication security services, key management and certification infrastructures, audit, and intrusion detection. * Requirements and designs for securing network information resources and tools -- WorldWide Web (WWW), Gopher, archie, and WAIS. * Requirements and designs for systems supporting electronic commerce -- payment services, fee-for-access, EDI, notary -- endorsement, licensing, bonding, and other forms of assurance. * Design and implementation of measures for controlling network communication -- firewalls, packet filters, application gateways, and user/host authentication schemes. * Requirements and designs for telecommunications security especially for emerging technologies -- very large systems like the Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Special issues and problems in security architecture, such as interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. * Integration of security services with system and application security facilities, and application protocols -- including but not limited to message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems Clifford Neuman, USC Information Sciences Institute REGISTRATIONS CHAIR: Donna Leggett, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Deadline for paper submission: August 14, 1995 Notification sent to authors by: October 16, 1995 Deadline for camera-ready copy: November 13, 1995 Submissions must be received by 14 August 1995. Submissions should be made via electronic mail. Submissions may be in either of two formats: PostScript or ASCII. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions should arrive well before 14 August. If electronic submission is difficult, submissions should be sent via postal mail. All submissions and program related correspondence (only) should be directed to the program chair: Clifford Neuman University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292-6695 Phone: +1 (310) 822-1511 FAX: +1 (310) 823-6714 Email: sndss96-submissions@isi.edu Dates, final call for papers, advance program, and registration information will be made available at the URL: http://nii.isi.edu/info/sndss Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 16 October 1995. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 13 November 1995. [Program committee and a few others deleted. PGN] ------------------------------ Date: Thu, 15 Jun 1995 19:45:13 -0400 From: Mike.Alexander@umich.edu (Mike Alexander) Subject: Re: Multo ante natus eram I, too, am glad to see that Multics is still used. It is a system that was far ahead of its time in many respects. In MTS (the Michigan Terminal System), a system contemporaneous with Multics which is also still in use, we solved the problem of the operators entering a bad time in a slightly different way. During initialization, the system compares the current time with the time in the last billing record recorded. If the current time is earlier or too much later (more than 12 hours, unless the day is Sunday in which case 18 hours is ok) it complains and asks the operators to confirm that the time is ok. This has several advantages: it doesn't use hard-coded dates, it is a more precise check, and it never makes the system unusable. Of course this has become less important as modern machines maintain the time of day even when not running and the clock rarely needs to be set at all. Mike Alexander, Univ. of Michigan Mike.Alexander@umich.edu MAlexander@aol.com ------------------------------ Date: Fri, 16 Jun 95 19:14:26 -0700 From: Mike_Crawford@quickmail.apple.com (Michael D. Crawford) Subject: Re: Multo ante natus eram Last fall I worked on the 2Market home shopping CD. This is a CDROM catalog with pictures of products from many popular mail-order catalogs, with QuickTime movies of TV commercials, and sound clips of record albums. One of the features of 2Market is that items go on sale. Of course the sales have to be prepared in advance, and the user will only get it right if their clock is set. Knowing my own habit of living in the year 1904, the Macintosh beginning of history (for no reason I can really fathom), I convinced the designers to let me put in a warning that your clock is off. The warning is placed in the message box that is normally used to inform the users that items are on sale. Any date that is before we shipped the CD, or after (I think) a year after the CD shipped warns the user to reset their clock. Shorter times afterwards give the user the number to order the next CD. Let's hope they always remember to update the code when they ship new versions... I'm not with Medior anymore to remind them. Mike Crawford Mike_Crawford@QuickMail.Apple.Com ------------------------------ Date: Sun, 18 Jun 1995 12:56:27 +1000 (EST) From: Richard Murnane Subject: Prodigy paranoid reaches Tasmania? The following recent news release from the Wireless Institute of Australia suggests that some people are getting very nervous, following the Prodigy defamation case in the USA: The name of the gateway is just one of those ironic little twists. :-) PACKET GATEWAY DEMANDS STAT. DEC. FROM AMATEURS The Launceston Institute of TAFE [Technical and Further Education] in northern Tasmania, which runs an amateur radio packet-to-Internet gateway known under the acronym of LITGATE, is requiring radio amateur users to file a statutory declaration with them. The relevant wording of the declaration says: "That I agree to take full personal responsibility for any information or data which is sent from my station, or from a station operating under my callsign. "That I will not hold the Launceston Institute of TAFE responsible for the content of data received through the LITGATE, whether such data is of an offensive, improper, illegal or other unacceptable nature." Basically, what the Launceston TAFE requires is that radio amateurs wanting access to LITGATE must say they will accept responsibility for all messages under their callsign, whether pirated or not, and agree they will absolve the Launceston TAFE from responsibility for any material placed on its system. Whether such a statutory declaration is legally binding would be a matter of conjecture. (Thanks to Victorian Division President, Jim Linton VK3PC, for details on that item). [end] I hope somebody can convince these people of the stupidity of their decision, as they clearly don't understand some of the technical issues. For those not involved in Amateur Radio, we "hams" operate our own computer network, using our radios as the physical layer. In some places, known as "wormholes" or "gateways", operators transport message over long distances via Internet, replacing the slower chain of short-range VHF or UHF radio links. The traffic leaves the net again at some remote point and rejoins the Amateur packet radio network. It's important to realise that the wormholes and Internet are merely being used as a medium for conveying this traffic from one part of the Amateur packet network to another; the Amateur traffic is effectively "quarantined" from other Internet traffic because Amateur Radio licence conditions forbid non-Amateurs (e.g. other Internet users) from conveying message by Amateur Radio. So, it would be very hard to argue that LIT is a "publisher" of any Amateur packet radio traffic passing through its gateway. I might add that it is a trivial matter to "pirate" another Radio Amateur's callsign. -Richard Murnane (Amateur station VK2SKY) ------------------------------ Date: Fri, 16 Jun 1995 21:00:42 GMT From: jthill@netcom.com (Jim Hill) Subject: Re: not caring about Prodigy (Morrell, RISKS-17.18) >hatred against Prodigy, which appears to be practicing the most control of >any provider (though still nothing like a newspaper) has people cheering ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think the risk is overstated, because (and only because) the underscored assertion is contradicted by Prodigy's own words: > "We make no apology for pursuing a value > system that reflects the culture of the > millions of American families we aspire to > serve. Certainly no responsible newspaper ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > does less when it carries the type of ^^^^^^^^^ > advertising it published, the letters it > prints, the degree of nudity and unsupported > gossip its editors tolerate." >(Exhibit J.) If Prodigy chooses to back off on their editorial control to, say (and the decision does say), Compuserve's or AOL's level, they won't be liable for the content they carry. Until then, they're providing a specific and valuable -- no irony intended, for any who might think newspapers aren't valuable -- service, and can be held responsible to the standards of that service. Jim Hill jthill@netcom.com ------------------------------ Date: Fri, 16 Jun 1995 16:06:34 -0400 (EDT) From: Bob Morrell Subject: Re: not caring about Prodigy I see your point, and hope you are right that the ruling will not have the broad effect I fear (though I have already heard it cited in exactly the manner I have described in a NPR report on another cyber-case) However, it is worth noting that your exhibit does not prove that Prodigy wanted to be a newspaper. It merely shows that Prodigy cited as an example of controlling content, newspapers. They could have cited restaurants that control dress codes, that would not have made them a restaurant. To say, when one is tired, that even horses get tired if you work them too long, does not make one a horse. To say that you have some rights, similar to one entity does not make you that entitity. This is the kind of square pegs in round hole legal thinking that I think harms the emerging character of the net. Bob Morrell bmorrell@isnet.is.wfu.edu ------------------------------ Date: Fri, 16 Jun 1995 13:42:57 -0800 From: jthill@netcom.com (Jim Hill) To: Bob Morrell Subject: Re: not caring about Prodigy "Certainly no responsible newspaper does less" in terms of controlling content -- "the letters it prints" -- says to me that they are *at least* as responsible as any newspaper. It's not just an example, it's an explicitly stated minimum standard. One doesn't have to be a prodigy (sorry ;-) to infer liability. I do agree with you that "rabid" is on target for too much of the anti-Prodigy froth. I will also say I was wrong to suggest earlier that moderated groups and lists should be held to that standard. Only the ones that claim it for themselves. Jim Hill jthill@netcom.com ------------------------------ Date: 24 March 1995 (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 (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [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. 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) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, 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 and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.19 ************************