Subject: RISKS DIGEST 14.01 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 04 November 1992 Volume 14 : Issue 01 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Tandem Clock Outage (J. Lyngved via Paul Hicks and Bruce Baker) Re: Air Inter A320 descent (Pete Mellor) Re: Leaving greasy marks on monitors may be dangerous (Pete Mellor) Re: Risks of Cellular Speech (Phil Karn, Dave King) Re: Cash dispenser fraud (Pete Mellor) Re: Caller-ID and Modems (A. Padgett Peterson) Re: Symantec/Borland [and Brazilian President] (Rob Horn, anonymous) Re: Interesting/obscure interaction between users (Jerry Leichter) Re: 15th NCSC - eavesdropping (Brinton Cooper, Carl Ellison) Re: New risk reports (Pete Mellor) ASEE '93 EPPD Call for Papers (Ken Sollows) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 14, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). 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. ---------------------------------------------------------------------- Date: 3 Nov 1992 15:27:25 -0800 From: "Bruce Baker" Subject: Tandem Clock Outage (collated from various sources) [Bruce sent me a stack of messages. This (slightly edited) is the most coherent, from J. Lyngved and forwarded via Paul Hicks of RPS Ltd. PGN] FROM: Lyngved.J In case you have not yet heard, our TANDEM stopped last night. So did almost all TANDEMS around the world, I've heard. We are currently trying to get it running again, helped by TANDEM people. Worse yet, they inform us that unless we do some upgrading it will stop again on January 7, 1993. This is not an April [fool's] joke. Jesper [I hope the details surface in RISKS. It appears that at 15:00 on the 1st, all Tandem CLX machines abended, causing the BASE24 Nucleus to dump with a Trap 2 (arithmetic overflow) in the procedure age-timers. A cold reload would get the system going again. Stay tuned (or detuned). PGN] ------------------------------ Date: Tue, 3 Nov 92 21:48:50 GMT From: Pete Mellor Subject: Re: Air Inter A320 descent It just *so* happened that I was in France last week (on something completely unrelated: an ISO meeting). I dropped into the office of a certain lawyer in Paris on my way out and back. On the way out, he gave me a photocopy of an article in "Le Canard Echaine", about Michel Asseline's book about the Habsheim crash. On the way back, he gave me two photocopies of articles in "L'Alsace" (regional newspaper serving Habsheim and surroundings), and "Le Monde", which had appeared that very day (Friday 30th Oct.) or the day before. The last two articles are detailed accounts of the "descente intempestive" which has been reported recently. If what the articles say is true, then it looks as though all bets are off regarding Bangalore, Strasbourg, AND the A300 and A310 crashes in Kathmandu. To summarise: When "rate of descent" mode is selected, (as opposed to "flight path angle"), a fault in the FMGS software occasionally causes the aircraft to descend at **2 or 3 times** the rate selected by the pilots. They don't even NEED to confuse "rate of descent" and "flight path angle"!!! This was reported by several crews who were able to recover the situation because they weren't flying over mountains at the time. The FMGS software (I *think*) is NOT regarded as SAFETY-CRITICAL!!!! If this is so, then it is NOT certified to RTCA/DO-178A level 1. The SAME FMGS is in use on A300, A310, and A320 (at least, *basically* the same)!! The French pilots' unions are up in arms about it, and in France generally, all hell seems to be breaking loose. Typically, in the UK press, the silence is deafening. (Presumably none of their French correspondents can speak French! :-) The other thing that my French lawyer colleague gave me was a signed copy of Michel Asseline's book about Habsheim: "Le Pilote - Est-il Coupable?" (You've guessed! He's Asseline's solicitor! :-) Since I read French even more agonisingly slowly than I read English, you'll have to wait a while for my detailed review. In the meantime, I will try to find time in the next few days to translate the three newspaper articles. If anyone sees anything in the media (French, UK, US and all points between), let us all know. Pete PS: If anyone knows of a publisher willing to handle the forthcoming English translation of Asseline's book, let me know about that, too. Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk ------------------------------ Date: Tue, 3 Nov 92 20:27:00 GMT From: Pete Mellor Subject: Re: Leaving greasy marks on monitors may be dangerous (RISKS-13.89) > Apparently, so I am told, CFCs have been replaced in these aerosols by > flammable propellants. Come back CFCs, all is forgiven! Actually, I suspect that most of the CFCs that hit the ozone layer come from decommissioned refrigerators or industrial waste, and not from you or I spraying our hair or computer screens. (Prince Charles is reported to have banned the use of CFC aerosols in the Palace. "Every little helps!", as the wren said when she pee'd in the ocean! :-) Why not go for the "Pump and Spray" approach adopted by a certain manufacturer of hair laquer? The lid of the can activates a pump. You push it up and down a few times to pressurise the can, and then spray out the contents with a propellant no more polluting (or inflammable) than compressed air. Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk ------------------------------ Date: Tue, 3 Nov 1992 02:29:38 GMT From: karn@qualcomm.com (Phil Karn) Subject: Re: Risks of Cellular Speech (RISKS-13.89) > In a three-month study of the Metro Toronto area earlier this summer, Bell > found that 80 percent of all cellular telephone traffic is monitored by third > parties. Even more eye-opening is the fact that 60 percent of monitored calls > are taped for closer scrutiny and culling of marketable information. I would very much like know how Bell Canada obtained these figures, given that the monitoring of cellular telephone calls from the privacy of one's home is essentially undetectable. > After discussing privacy laws, legalities, and realities, Flinn notes that at > Scanners Unlimited in San Carlos, CA, "about a quarter of the customers are > interested in telephone eavesdropping." This problem will soon be stopped cold, as Congress recently passed a law to outlaw the manufacture of scanners capable of receiving cellular telephone calls. A truly inspired solution to the problem, comparable to the "B-Ark" people in "The Hitchhiker's Guide to the Galaxy" burning down the forests to solve the inflation problem caused by making leaves legal tender. Phil ------------------------------ Date: 03 Nov 92 16:47:58 EST From: Dave King <71270.450@compuserve.com> Subject: Risks Of Cellular Speech I must apologize to the list. I have been informed that we cannot confirm the percentage figures that were mentioned in the note that I quoted in the item that I posted yesterday concerning a study of the monitoring of cellular traffic in Toronto, Canada. David L. King, IBM Southeast Region I&TSS, Mail Drop D072, 10401 Fernwood Road Bethesda, Maryland 20817, (301) 571-4349 ------------------------------ Date: Tue, 3 Nov 92 20:39:33 GMT From: Pete Mellor Subject: Re: Cash dispenser fraud (RISKS-13.89) Erling Kristiansen writes (concerning cash dispenser fraud): > If you do not take your money within a given time, the machine will swallow > it back, and undo the transaction on your account. Not in my experience. (See RISKS about a year ago.) I simply forgot to take the money, and the machine swallowed it. To get the amount credited to my account, I had to 'phone the bank personally, and the amount was only repaid after the till had been (manually) balanced, and the excess cash in stock verified. Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk ------------------------------ Date: Tue, 3 Nov 92 10:33:50 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Caller-ID and Modems (Slade, RISKS-14.01) I realize that this may be a bit out of the ordinary for a RISKS posting but since Rob Slade raised the issue in RISKS yesterday, I have gotten quite a few questions. First, it is my belief that much of the RISKS of dial-up access points is increased by the ease of discovering such points. War Dialer and Exchange Hacker programs are plentiful and have contributed to a number of notorious cases recently (the MOD is said to have used this method of discovering such lines). The problem is that with all current systems that I am aware of, it is first necessary for the modem to answer the telephone before any authentication can take place. By doing so, the line may be positively identified as having a modem even if call-back or other rigorous identification means are in use. Once such line have been identified, serious penetration attempts can take place. When announced, it was realized that Caller-ID provided an answer to this dilemma that was much better than the "ATS0=7" which I previously advised. (This command instructs a modem responding to the "AT" command set not to answer the phone until the seventh ring - typically about 40 seconds after connection starts. Since most War Diallers allocate only 30 seconds to each number, this is an effective, if annoying, answer). Caller-ID places a 1200 baud digital signal on the telephone line between the first and second ring signal. The important factor is that the phone does not have to be answered to received this information. Some modems are able to pick up this signal and present it to the host computer. What I did last weekend was to create a PROCOMM PLUS script file using their ASPECT language to do the following: 1) When the telephone rings the calling number is captured. 2) The number is recorded into a "LOG" file and then a scan of a database of "approved" numbers (flat ASCII) is done. 3a)If the number is found in the "approved" file, PROCOMM is instructed to enter its "HOST" mode - an effective single line BBS emulation that supports uploads/downloads/mail/and "chat" and the phone is answered. or 3b)If the number is not found, the line is not answered 4) After the caller hangs up, the system resets. Given this, even if the "bad guys" know the number, they will still have to find a way to induce the modem to answer the line. Certainly if this were in widespread use, much of the plot of "Sneakers" would have had to be re-written. Yes, I know that there are problems, particularly with "roving" people. If however 80-90% of all access could be handled in this manner (e.g. for telecommuters), the balance could use extraordinary means. Right now the capability is limited to a PC running PROCOMM Plus 2.01 and equipped with a Supra Corp. SupraFAXmodem having the Caller-ID ROM upgrade. I haven't tried any others. Why did I choose this combination ? - because I had them (both were privately purchased) and they would do what was necessary - this is all a hobby to me. In theory any Caller-ID unit with an RS-232 output could be used as could any scripting BBS software. What was desired was a "proof-of- principle" not a commercial product. The PRIVACY concern is easily handled: you can block your number from Caller-ID (star-6-7 in most places) but I reserve the right not to have my computer answer the phone if you do. IMHO this capability is still in its infancy but is important and easily implemented, we are just seeing the tip of the iceberg now. Right now the biggest drawback is the limited availability of Caller-ID though IMHO again it will be nationwide in two years (law enforcement agencies already have a wider coverage so the holdup is political, not technical). RISKS ? To me the most important is the question "Could an individual use star-6-7 to block the telco's ID and send their own 'approved' 1200 baud stream ?" The consensus so far is "NO" and I have some friends at GTE experimenting. In any event, the script is FreeWare for anyone who might be interested, just be aware that I do not have any distribution means (might be able to send as E-Mail) and negative free time. The importantance of this is that it is no longer theory, it is now fact, CHEAP fact. Padgett ps: Just to avoid the inevitable, Supra Corp. can be reached in Oregon at (800)727-8647 (do not think Caller-ID is available outside the US yet). I bought mine from a mail-order house for about 3/4 list price. PROCOMM is a product of Datastorm Inc. (800)326-4999 (plugs) ------------------------------ Date: Tue, 27 Oct 1992 08:08 EST From: HORN%athena@leia.polaroid.com Subject: Re: Privacy of e-mail (Symantec/Borland suit) For further commentary on this issue, see the recent Forbes magazine article by Mitch Kapor. It raises the issues of how the ECPA Act and similar California privacy legislation might apply to this case. It will probably make a number of lawyers rich and drag on for years, but there are some very complex legal issues involved. The issue involves MCI's responsibility as an e-mail provider under ECPA and whether Borland was or was not authorized to have access to Wang's mail. I doubt that all the relevant facts are yet public. Rob Horn horn%hydra@polaroid.com ------------------------------ Date: Sun, 1 Nov 92 15:19 PST From: [anonymous] Subject: Symantec/Borland and Brazilian President There are two topics in RISKS-13.87 that are actually related. Someone asked about software that could have been used to get the deleted files from the Brazilian president's disks. There was also a mention of the Symantec/Borland suit over theft of trade secrets. The Wall Street Journal had the most complete article about the latter (I don't have the date handy) and mentioned that Borland used a copy of a Symantec product, Norton Utilities, to recover erased files that are being used as evidence in the case against Symantec. Apparently Norton Utilities is widely used by law enforcement agencies for gathering evidence in cases involving PCs. The product also includes a utility for ensuring that deleted data cannot be recovered, but many people seem to think that if they "delete" a file and it seems to be gone, then that's what really happened to it. There's always a risk when a user's model of what the computer is doing behind the scenes is a simplified one which is adequate for doing their work, but not for predicting the outcome of unusual circumstances. ------------------------------ Date: Sat, 31 Oct 92 13:51:06 EDT From: Jerry Leichter Subject: re: Interesting/obscure interaction between users (Honig, RISKS-13.88) David Honig remarks on his discovery that users of SunOS can allocate shared memory resources and fail to delete them properly, thus effectively rendering them unavailable to later programs, which fail. Only a reboot will resolve the situation. A couple of remarks: a) All the Unix System V IPC objects have this property. Allocating and failing to free shared memory segments, semaphores, or message queues, all of which exist in limited numbers and cannot be replenished, can also cause later numbers to fail. Mr. Honig remarks that there are typically 100 memory segments. There are typically considerably fewer semaphores or message queues. b) This is not a SunOS problem; it's inherent in System V, which defines a set of IPC facilities which allow objects to persist even though no one is using them. Programs probably exist which rely on this, so I doubt it can be changed. c) It IS possible to recover from this without rebooting, since root can attach to the "lost" objects and delete them. Of course, you have to find them first. At least on Ultrix, and probably on most other systems, there is a program (ipcstat, I think) which displays a list of all IPC objects in the system. It would remain up to a human being to decide which ones can be deleted safely, however. d) Given (c), the situation is, in a way, analogous to running out of disk space because the disk is full of old junk. This similarity, however, is tenuous, for several reasons: Disks are much larger than the sets of IPC resources available; the names of files being created are generally known, except for temporary files - which as a matter of policy are treated as expendable after a short time, and automatically cleaned up; and people regularly see directory lists, but they rarely if ever have reason to run ipcstat. -- Jerry ------------------------------ Date: Mon, 2 Nov 92 23:38:32 EST From: Brinton Cooper Subject: Re: 15th NCSC (Denning, RISKS-13.87) First, I should hate to think that my right to safety from illegal search and seizure and/or illegal eavesdropping on my telephone conversations rested on the good will and integrity of a phone company! Second, it's difficult to envision a non-governmental agency, created by the government but not really government. The Post Office purports to be a non-governmental agency but isn't. It's employees still look and act like US Civil Servants, and the P.O. can easily conduct a "mail cover" for a governmental agency without a court order. You must remember that court orders, search warrants, and the like are useful only when the information or evidence gathered under their aegis is to be used in court against a suspect. If information is being gathered for political purposes, to blackmail someone, or to subvert the law (Watergate, Iran-Contra, the Italian bank, etc), the information will never see a public forum. Thus, the constraints of court orders are obviated. The FBI needs to fund its own R&D out of its budgetary resources, just as the rest of the government at all levels must do. There is talent that can "red team" modern telecommunications and find trapdoors when necessary. You must never forget that the gravest threat to our freedom is, and always has been, government itself. _Brinton Cooper ------------------------------ Date: 30 Oct 92 21:42:12 GMT From: cme@ellisun.sw.stratus.com (Carl Ellison) Subject: Re: Key registration (Denning) In the exchange over Dr. Denning's proposed key registration agency, I have learned that there are civilized countries out there (eg., Finland) where it is illegal for the government to do a wiretap. Even getting phone records in Finland (for traffic analysis) apparently results in the target's being told. Sadly, we're not that civilized, it seems. I can imagine some large company (one of the Baby Bells, perhaps) making a line of scrambled, digital phones -- perhaps cellular -- perhaps just wireless, but with digitization and end-to-end encryption done in the handset. I could see this line of phones using RSA (1000 bit) to pass triple-DES keys around (DES with 3x56 bit keys and 3x64 bits of random IV for CBC mode). I can imagine that large company offering to register keys for the FBI -- just to keep from being hassled by the Gov't. Were that to happen, I might even buy such a phone -- knowing that it's insecure but also knowing that my neighbor won't be listening in on her wireless phone. However, it's important that the agency which releases keys not release the RSA keys (in this case) but rather the session key (360 bits of DES key and IV) of a particular conversation. Releasing the RSA key makes the phone in question insecure for all time, past and future. (No, I don't advocate key registry -- but if it looks like we end up having it, let's have it limited. Meanwhile, it's perfectly reasonable to have an audit trail of all such taps made available to major news organizations immediately and eventually to the person targetted -- so that any Nixon-like abuses would get caught and prevented.) Carl Ellison, Stratus Computer Inc., M3-2-BKW, 55 Fairbanks Boulevard, Marlborough MA 01752-1298 cme@sw.stratus.com (508)460-2783 FAX: (508)624-7488 ------------------------------ Date: Mon, 2 Nov 92 20:30:01 GMT From: Pete Mellor Subject: Re: New risk reports (Bowen, RISKS-13.87) Please see also: "Living with Risk", The British Medical Association Guide, John Wiley & Sons, 1987, ISBN 0 471 91598 X, 16.45 sterling. (Winner of the 1988 Science Book Prize.) Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk ------------------------------ Date: 3 Nov 92 09:56:12 ADT From: "Ken Sollows" Subject: ASEE '93 EPPD Call for Papers CALL FOR PAPERS ENGINEERING AND PUBLIC POLICY DIVISION 1993 ASEE ANNUAL CONFERENCE UNIVERSITY OF ILLINOIS, URBANA, IL JUNE 20 - 24, 1993 Presentations and papers are invited on educational aspects of Engineering and Public Policy. Any related topic will receive consideration, however, suggested topics for sessions are the following: * Energy and Environmental Policy * The Role of Colleges of Engineering in Shaping Public Policy * Public Policy in the Undergraduate Engineering Curriculum * Governmental Initiatives in Engineering Education * Educational Policy and Economic Growth Deadline: 500 word abstracts due December 1, 1992 Presentations will be selected by the EPPD program staff based on abstracts only. Authors who also wish to submit their papers for publication in the conference Proceedings must submit a draft for peer review by January 15, 1993. There will be a page charge for publication. Include title, author's name, work address, and telephone number. Abstracts and papers should be submitted to the EPPD Program Chair: Dr. P. Paxton Marshall, Department of Electrical Engineering University of Virginia, Thornton Hall, Charlottesville, VA 22903-2442 Tel: (804) 924-6076 Fax: (804) 924-8818 e-mail: marshall@virginia.edu Ken Sollows, Dept. of Engineering, UNBSJ Email: sollows@unbsj.ca Ph: (506) 648-5583 FAX: (506) 648-5528 ------------------------------ End of RISKS-FORUM Digest 14.01 ************************