Subject: RISKS DIGEST 17.57 RISKS-LIST: Risks-Forum Digest Thursday 21 December 1995 Volume 17 : Issue 57 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ********************* HAPPY AND RISK-FREE HOLIDAYS *********************** ***** See last item for further information, disclaimers, etc. ***** Contents: Problems with computerized "translation" (Jesper Holck) German Windows 95 dishonors write-protection (Arslan Broemme) German service providers must maintain covert customer databases? (Wilhelm Mueller) The cellular-phone encryption debate in Israel (Jonathan Kamens) Domain Registration RISK? () Risks of Checking Accounts (Gary M. Watson) Re: Naval Battleship takeover - I don't think so. (InfoWar moderator) Re: Indelible words (Andrew Marc Greene) Re: Medical diagnosis by computer (Bob Morrell) Re: Definitions for hardware/software reliability ... (Pete Mellor) Pilot-in-command authority (Re: a well-managed risk) (Andrew Koenig) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 21 Dec 1995 16:04:45 +0200 (METDST) From: Jesper Holck Subject: Problems with computerized "translation" A few months ago I was looking in the table of contents for the Danish users' guide for Windows for Workgroups 3.11, and I noticed some very peculiar words like "Stogardinstallation" and "ogre". I know most readers of this mail are not able to read Danish, but these are certainly not ordinary Danish words. At last I managed to find an explanation to these strange words. Apparently someone wanted to "translate" the English word "and" to the equivalent Danish word "og". And made this "translation" using a simple search-and-replace. So "standard" became "stogard", "andre" (other) became "ogre" and so on ... I hope Microsoft will be able to find some better ways of translating from English to Danish in the future. Jesper Holck, Ballerup Business College, P.O. Box 40, DK-2750 Ballerup DENMARK holck@dat.ruc.dk or hanibal@inet.uni-c.dk +45 44 97 3597 Fax: +45 44 68 3350 [This method might be known as "hog to mouth", where a "dandy" becomes a "dogy", a "landslide" a "logslide", and quite appropriately a "sandwich" becomes a "sogwich". This is definitely worthy of a Victor Borge scene, along the lines of his world-famous "off-by-one" (+1) routine. PGN] ------------------------------ Date: Wed, 20 Dec 1995 23:28:12 +0100 From: Arslan_Broemme@public.uni-hamburg.de (Arslan Broemme) Subject: German Windows 95 dishonors write-protection My name is Arslan Broemme. I'm a student of computer science at the University of Hamburg (Germany). While watching airplanes land with my girl-friend, I heard on Radio Hamburg (moderator: K.D. Ackermann, 12 Dec 1995, 22:10h and again at 23:15h) that it is possible to format write-protected disks when using the German version of Windows 95. http://www.informatik.uni-hamburg.de/Arbeitsbereiche/AGN/people/broemme/ arslan.html Arslan_Broemme@public.uni-hamburg.de ------------------------------ Date: 21 Dec 1995 13:44:09 +0100 From: muewi@informatik.uni-bremen.de (Wilhelm Mueller) Subject: German service providers must maintain covert customer databases? This is an excerpt from an article that appeared in the weekly German newspaper *Die Zeit*, No. 52 (22 Dec 1959), p.58 (Bulkware/Telephon-CD gestoppt). [literal translation by WM] [*emphasis* below is *Die Zeit*'s] [further translation by PGN, respecting the original German (not included)]: For others, though, address data will suffice only if it can be easily compared with other databases. Such a practical ["praktisches"!] information system is needed by the German government and secret services. Paragraph 92a TKG-E of a proposal for a new *telecommunications law* published last week would oblige all telephone companies, on-line services, and even private mailboxes to maintain a database at their own expense containing the full names, addresses, and phone numbers of *all customers* -- in case someone is under suspicion. This database must be organised so that it can be accessed by higher places ["hoeheren Orts"!] without the telecommunication provider noticing it. Wilhelm Mueller, Am Wall 139, D-28195 Bremen (office) +49-421-361-10629 muewi@informatik.uni-bremen.de (home) +49-421-169 2525 [Ah, mandatory trap doors are a wonderful opportunity for misuse, internally and externally. We've been around this topic in RISKS many times before, but this is a new context. PGN] ------------------------------ Date: Wed, 20 Dec 1995 15:07:07 GMT From: Jonathan Kamens Subject: The cellular-phone encryption debate in Israel An article headlined "Knesset considers lack of protection against cellular phone eavesdropping" and sub-headlined "Communications Ministry director-general: Databases can be easily entered", by Evelyn Gordon, appeared in today's "Jerusalem Post". Some excerpts: ************************* Cellular phones are completely unprotected against electronic eavesdropping, and the same is true of many databases and even some regular phone lines, the Knesset Economics Committee's consumer affairs subcommittee was told yesterday. ... "All of the public databases in Israel can be very easily entered," [Shlomo] Wachs [Communications Ministry director-general] added. "And there are some towns in Israel connected to the telephone via microwave transmissions, and it is possible to listen in on regular phone calls via every such transmission." [sic] ... Hanan Achsaf, general manager of Motorola, said that instructions for eavesdropping on cellular phones are available on the Internet, and therefore are now public domain. [Apparently (summarizing from another recent article in the "Post"), someone recently posted instructions for activating a "debugging" mode in Israeli cellular phones which causes them to pick up any calls being carried on by other cell-phones in their vicinity. I don't think there's anything special about Israeli cell-phones, so I suspect that cell-phone networks in other countries are also vulnerable to this attack.] Both Eyal Levy, managing director of Pelephone [one of the Israeli cell-phone networks], and Shalom Menuba, deputy managing director of Cellcom [the other one], said that while they could not prevent eavesdropping, they had the capability of knowing when it was happening and who was responsible. [[SEE BELOW.]] ... Menuba also said Cellcomm phones are technically capable of encoding conversations, and that the company would examine the feasibility of allowing customers to do so. Wachs, however, opposed this idea, noting that even in the US, encryption is illegal for security reasons. [[SEE BELOW.]] Achsaf said that in any case, the technology was still in the experimental stage, and not yet ready for commercial use. ... ************************* In response, I sent the following letter: ************************* December 20, 1995 Shlomo Wachs, Director-General Ministry of Communications The Knesset Jerusalem Dear Mr. Wachs: I am writing to correct two serious errors in the testimony about cellular telephone security presented to the Knesset Economics Committee's consumer affairs subcommittee on December 19, as reported in The Jerusalem Post on December 20. The Post reported, ``Both Eyal Levy, managing director of Pelephone, and Shalom Menuba, deputy managing director of Cellcom, said that while they could not prevent eavesdropping, they had the capability of knowing when it was happening and who was responsible.'' That is simply not true. The signals which carry cellular telephone conversations can be listened to by anyone with a radio scanner capable of being tuned to the correct frequencies. While it may be true that Pelephone and Cellcom can detect eavesdropping done using the instructions recently made available on the Internet (since those instructions pertain to the use of regular cellular telephones, rather than scanners, to eavesdrop on conversations on other phones), they cannot detect or identify those who eavesdrop using scanners. The Post further reported that you oppose the use of encryption to protect cellular telephone conversations, and that you claimed that ``even in the US, encryption is illegal for security reasons.'' This, too, is simply not true. There are currently no restrictions in the United States on the use of encryption to protect cellular telephone conversations. Plans to enact such restrictions have been proposed by the government, but those proposals have been received so negatively by American civil-liberties advocates that none of them has succeeded, and it is not clear if any of them will. It is clear that there are serious privacy problems with unencrypted cellular-telephone conversations. It is also clear that prohibiting their encryption will not help security, since anyone who has a desire to do anything illegal using a cellular telephone will be willing to use encryption whether or not it is legal. I therefore urge you to reconsider your stand, and to encourage cellular telephone carriers in this country to make encryption available to their subscribers. Sincerely, Jonathan I. Kamens cc Editor, *The Jerusalem Post* FAX: 02-389-527 ------------------------------ Date: Thu, 21 Dec 1995 09:36:26 -0500 From: [Identity withheld by request] Subject: Domain Registration RISK? I administer an ISP that owns the name XXXXs.net; and sent in a request to the InterNIC [Domain Registration Role Account ] to update our list of nameservers. Unfortunately, I made a typo and left off the last character ("s") of the domain name. The update went through anyway, changing someone else's entry so that the entire planet will think they should contact US for his address info instead of his real servers. I immediately sent a note to the NIC informing them of the mistake. It's now >18 hours later and I haven't heard back from them. As the reply from the NIC indicated, root server updates for this change won't happen until 5 PM tomorrow ... the Friday before XMAS ... The RISKs are rather obvious. [Attached correspondence deleted for RISKS. PGN] ------------------------------ Date: Wed, 20 Dec 1995 17:00:14 -0800 (PST)F From: trimm@netcom.com (Trimm Industries) Subject: Risks of Checking Accounts A couple weeks ago I was depositing a check at an ATM, filled out the deposit slip, and was ready to seal it in the envelope when something attracted my attention to the name on the deposit slip -- it wasn't mine! It came out of my pad of (correctly) printed checks, but about half of the deposit slips in the pad were some other guy, from a different state, with a different account number AT A COMPLETELY DIFFERENT BANK! Now, I understand that check printers service many different banks, but this guy's name was distant from mine alphabetically and the account number was quite different. The RISKs here are several and obvious, such as what fate befell _my_ deposit slips, but alas as yet no one has deposited money into my account by using one of my deposit slips by mistake. Okay, life is weird and all that, but the very next week BofA accidentally included someone else's bank statement in with mine, including all their cancelled checks. It occurs to me that this would be a goldmine for a swindler -- here I had a sample of the person's signature, their (substantial) starting and ending bank balance, their check style and account number, as well as their home address. Thus far, not much for a crook to go on. But here's the kicker -- the person paid her phone bill and put her unlisted phone number on the Memo line, paid her Visa bill and put her Visa number on the Memo line, and paid some other bill whose account number was her Social Security Number with an alphabetic prefix, and this was on the Memo field of the appropriate check. I had a dossier on this person and if I was a swindler I could have ruined her life. The RISKS: 1. Banks are idiots. Don't trust them to keep your secrets. 2. Don't put all sorts of important numbers on check Memos. 3. Keep in mind that people can _steal_ your checking statement from your mail. 4. Merchants: don't assume that because someone has a few personal numbers of someone that they are indeed that person. 5. Consider letting the bank store your cancelled checks on microfilm for you (but keep #1, above, in mind.) Gary M. Watson Sigma-Trimm Technologies trimm@netcom.com 350 Pilot Road, Las Vegas, NV 89119 Phone: (800) 423-2024 x2115 [This is clearly RISKS relevant, although some of you may wonder about the computer-relevance. The bottom line seems to be that if we blindly trust technology, we may be more easily led astray. PGN] ------------------------------ Date: Thu, 21 Dec 1995 10:14:42 -0500 (EST) From: iw@all.net (Information Warfare Mailing List) Subject: Re: Naval Battleship takeover - I don't think so. (Long, RISKS-17.55) I thought RISKS readers might be interested in this moderator's note from the IW mailing list, responding to the earlier message in RISKS-17.55. Moderator's Note: Subject: Navy hacked by Air Force I talked to some people I know about the purported IW attack on a battleship by the Air Force, and I thought I would help debunk this story, which my contacts tell me is "wildly inaccurate", but looking at a few facts. Let's start with the title: > War of the microchips: the day a hacker seized control of a US battleship No!!! There are NO active US battleships!!! And there weren't any last September. ... > BY SIMPLY dialing the Internet and entering some well-judged keystrokes, > a young US air force captain opened a potentially devastating new era in > warfare in a secret experiment conducted late last September. His > target was no less than gaining unauthorised control of the US Navy's > Atlantic Fleet. According to my sources this was not "SIMPLY dialing the Internet and entering some well-judged keystrokes". It was a controlled experiment with participation of both Navy and Air Force, and involved a great deal of planning by a large number of people. It was performed using DoD owned and properly keyed cryptographic devices designed to be allowed to communicate with the systems being attacked. > He was armed with nothing other than a shop-bought computer and modem. > He had no special insider knowledge but was known to be a computer > whizzkid, just like the people the Pentagon most want to keep out. 100% wrong - he was an insider, he had a great deal of assistance, he had cryptographic devices and keys, and he had special insider knowledge. If he was a Navy captain, he could not have been all that young. Whizzkids are usually considered teenagers. Anyone know of any teenaged Navy captains? > A few clicks and whirrs were the only signs of activity. And then a > seemingly simple e-mail message entered the target ship's computer > system. ... > targeted ships surrendered control as the codes buried in the e-mail > message multiplied inside the ships' computers. A whole naval battle > group was, in effect, being run down a phone-line. Fortunately, this Not quite. This was not an e-mail sent from some Internet site and e-mail messages did not multiply inside the ships' computers. Furthermore, the total bandwidth of a phone line is nowhere near enough to "run" a naval battle group, or probably even a naval kitchen for that matter. > The exact method of entry remains a classified secret. The first really true part of the story. ------------------------------ Date: Thu, 21 Dec 1995 13:12:49 -0500 From: "Andrew Marc Greene" Subject: Re: Indelible words (Hawthorne, RISKS-17.56) After reading Brian Hawthorne's discussion of the altavista search engine, I had to try it. Not only did I find all sorts of things that I wrote (or that people wrote about me :-) going back to 1988, but I tried something else even more enlightening: I did a web search for my URL. It's amazing who has links to my homepage or to one of the two other web sites that I run. Yahoo thinks I'm an entertainer (one of the sites I host is for a chorus that I sing in). People I've never heard of have links into my stuff. This is great news. The things I put on the web are useful enough that people want to link to them. I'm proud and happy. On the other hand, I now have a list of about thirty people who are interested in Jewish law or Jewish music. If only I were trying to sell them something... :-) - Andrew Greene ------------------------------ Date: Wed, 20 Dec 1995 10:30:38 -0500 (EST) From: Bob Subject: Re: Medical diagnosis by computer (Herbkersman, RISKS-17.56) > As a sometime programmer and dabbler in databases, I find this news > exceedingly disconcerting. It is the best reason I can think of for staying > well. At any rate, please read the rest of the article. Medical expert systems are nothing new, and should not really be all that frightening to people. Remember, your doctor is an expert system, operating on rules derived from his education (programming), his experience (case database) and on the data input (your complaints). Computerized expert systems have several advantages to offer. Consider for instance, the number of physicians currently *not* treating and curing ulcers, because they have not gotten up to speed on this new therapy. An expert system, managed receiving updates from the best in each field, would make that change overnight. Computerized expert systems would also not be influenced by factors such as a very whining child and a overly worried mom, that might lead to over-prescription of antibiotics and other unnecessary therapy. There are risks to medical expert systems: over-reliance by physicians and the loss of skills that entails, "gaming of the system" by patients desiring certain therapies or diagnosis, failure to recognize unusual cases outside the systems case-base, but note that many of these risks exist in some form or another with human physicians. I have worked for several years now with another kind of medical es, the simpler, "inspector" kind that monitors human-guided therapy and attempts to find "discrepancies", so my bias on this matter is clear. I maintain however, that this technology has matured well past the point where it offers positive gain to the patient. Much of the resistance to it is founded not on fear of mistakes but on fear of loss of status by physicians. Enter the new world with your eyes open and quick to question your care, but frankly, you should have been doing that all along.... Bob Morrell http://www-uk.hpl.hp.com/people/ewc/list-main.html#HDR13 bmorrell@bgsm.edu ------------------------------ Date: Wed, 20 Dec 95 19:40:34 GMT From: Pete Mellor Subject: Re: Definitions for hardware/software reliability ... (RISKS-17.56) I was interested to note that the references cited under "Failure" (surely the most frequently defined term in the field) include:- > The termination of the ability > of an item to perform a required function (BS4778) (O'Connor81). However the full set of references here is (excuse the Latex format): BS 4778: ``Quality Vocabulary'', Part 3: {\em Availability, reliability and maintainability terms\/}, Section 3.1: ``Guide to concepts and related definitions'', British Standards Institution, 1991. IEC 50(191): ``International electrotechnical vocabulary'', Chapter 191: {\em Dependability and quality of service\/}. This has been dual-numbered as Section 3.2 of the British national standard:-- BS 4778: ``Quality Vocabulary'', Part 3: {\em Availability, reliability and maintainability terms\/}, Section 3.2: ``Glossary of international terms'', British Standards Institution, 1991. The extract also fails to mention:- ISO~8402 : 1986, {\em Quality - Vocabulary\/} ISO/IEC~9126: 1991(E) ``Information technology -- Software product evaluation -- Quality characteristics and guidelines for their use'', first edition, 1991-12-15 These omissions are somewhat surprising, given that IEC/TC56 is the technical committee (TC) of the International Electrotechnical Commission (IEC) working on "dependability" (i.e., reliability, availability, maintainability and similar concepts, excluding "safety" which is the responsibility of TC65), and that both it and ISO/IEC JTC1 (Joint Technical Committee 1, whose subcommittee SC7 is responsible for 9126) are currently very active. This makes me suspect that, despite its June 1995 publication date, M.J.P. van der Meulen's book is grossly out of date in several important respects. As Principal UK Expert (PUKE - Gentlemen, I kid you not! :-) on "definitions of terms", representing BSI committee DS/1 on IEC/TC56/SC1, I have been working in this area for several years. (The main qualification is the ability to sit through a three-hour argument about the difference between a "functional unit" and an "item" without committing hara-kiri! :-) You might be interested to know that, following the receipt of DD198 from its public comment phase, BSI DS/1/-/1 (Why the "-"? Just DON'T ask!) is now working on turning it into a fully issued Part 8 "Assessment of Reliability of Systems Containing Software" of BS5760 "Reliability of Systems, Equipment and Components". Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, p.mellor@csr.city.ac.uk ------------------------------ Date: Thu, 21 Dec 1995 11:47:16 EST From: Andrew Koenig Subject: Pilot-in-command authority (Re: a well-managed risk, RISKS-17.47) Steve Fenwick and Robert Dorsett responded to me [Not included here. PGN] about emergencies, and I am in complete agreement with them. However, I think it's worth saying again that my original message talked not about emergencies but rather about procedures to manage risk on ordinary flights. The two procedures I thought well-chosen were (a) picking a closer `destination' to allow for 10% slop in fuel estimation and (b) requiring independent confirmation before changing the official destination to match the real one. After reading the various comments, I still think they are evidence of well-considered risk management. Andrew Koenig ark@research.att.com ------------------------------ Date: 6 September 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED info on RISKS (comp.risks) The RISKS Forum is a moderated digest. Its USENET equivalent is comp.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. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] 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. [...] 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. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://unix.sri.com/risks [if your browser accepts URLs.] ------------------------------ End of RISKS-FORUM Digest 17.57 ************************