Subject: RISKS DIGEST 18.71 RISKS-LIST: Risks-Forum Digest Monday 23 December 1996 Volume 18 : Issue 71 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, caveats, etc. ***** Contents: [HAPPY HOLIDAYS. RISKS takes a break, but risks probably won't.] Ghost 911 calls: software upgrade brings police (Timothy L. Kay) Re: Ghosts (PGN) Bright Field accident in New Orleans (Michael Quinlan) ACTION ALERT: Stop the spread of personal information on the net (Jon Handler) "Cryptography Policy and the Information Economy" draft available (Matt Blaze) Security vulnerability in CERN access protection (Christopher Fraser) Re: Emergency Key Recovery and Reconstruction (Adam Shostack, Bill Murray) Protean documents (Daniel P. B. Smith) Re: Problems of "unforeseen" system aging (Andrew Koenig, Paul E. Bennett) Re: PCs and configuration management (Henry G. Baker) Microsoft documents and Rosetta stones (Darrin B. Jewell) Re: Arrogance of Micro$loth Products (Bob Vaughan, Jonathan I. Kamens) Secure passwords on the web? Not at Microsoft! (Andrew Marc Greene) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: 21 Dec 1996 18:11:59 GMT From: "Timothy L. Kay" Subject: Ghost 911 calls: software upgrade brings police I use software that sends pages by dialing my modem and communicating directly with the paging company's paging terminals. I was using first-generation software that didn't understand area codes, so I had to enter the full dial string, 1-408-xxx-xxxx of the paging terminal. It worked fine. Then I downloaded a new version of the software, which is much more "intelligent" about area codes and dialing. It now expects the user to enter numbers without the leading 1, such as 408-xxx-xxxx. (I didn't know this.) If the number matches your area code, it strips the area code. Otherwise, it adds a 1 before the number. The new software also defaults to a PBX configuration in which you have to dial 9 to get an outside line. (I didn't know this.) I tried my first page. The software compared my area code (415) with the prefix of the number it was to dial (1-408-xxx-xxxx). It found that 415 does not match 140, and therefore prepended a leading 1. It also prepended a 9 to get an outside line. The software then dialed 9-1-1-408-xxx-xxxx The police showed up about 5 minutes later. They confirmed my phone number and asked why I didn't answer their return call. I replied that it is my modem number, and I thought somebody was sending me a fax. I have reported this problem to the software manufacturer, and I assume they will address the problem. In their case, upgrades to their software lead directly to the problem I described. (The tech support person replied that my description probably explains "something else that was happening.") Bad design aside, a simple practice should be observed whenever software dials the phone: the software should have a sanity check to make sure that 911 isn't being dialed. For that matter, wouldn't it make sense for modem manufacturers to include such a sanity check in their modem firmware? Are there legitimate reasons for a modem to dial 911? Tim [Yes, but also Yes. PGN] ----------------------------- Date: Mon, 23 Dec 1996 8:15:24 PST From: "Peter G. Neumann" Subject: Re: Ghosts (RISKS-18.70) Well, Timothy gives us another example of ghost phone calls. Long-time RISKS readers will recall * RISKS-2.27: Ghost phone calls to 911 from cordless phone interference when batteries ran down * RISKS-16.88: Calling Number ID ghost calls (from preprogrammed demo model?) In response to my BART ghost-train item in RISKS-18.70, a RISKS reader asks, WHAT IS A GHOST TRAIN? Answer: A train that isn't there but that the computer believes IS there. Here are a few from the RISKS archives: * SF Muni Metro: Ghost Train recurs, forcing manual operation * SF Muni Metro: Ghost Train reappears; BART problems same day * Chunnel has ghost trains, emergency stops (due to salt water?) * `TCAS Sees Ghosts' (see IEEE SPECTRUM, August 1991, p.58) * Chicago's O'Hare Airport radar lost planes, created ghosts It all ghost to show, especially if you are in the show. ------------------------------ Date: Sat, 21 Dec 1996 22:45:08 GMT From: mikeq@primenet.com (Michael Quinlan) Subject: Bright Field accident in New Orleans [Surprised?] ``The captain also acknowledged forgetting he had a computer override button on his console that could have allowed him to bypass the computer and increase the ship's speed and maneuverability.'' Michael A. Quinlan mikeq@primenet.com http://www.primenet.com/~mikeq ------------------------------ Date: Mon, 23 Dec 1996 10:52:55 CST From: Jon Handler Subject: ACTION ALERT: Stop the spread of personal information on the net By permitting individuals to publish information about themselves and their activities, the Internet has become a powerful tool for creating new social connections across the barriers of geography and background. Recently, though, several firms have started abusing the power of the Internet to publish large databases of personal information without permission. This is impolite, and it many cases it can even be dangerous. True story: recently, I followed a lead from MacUser magazine to a web page for dealing with spam e-mailers. That page suggested that one of the first steps to take was to contact services that track people's e-mail addresses. With growing horror, I connected to page after page on the list and located myself in their databases. Some services listed far more than just name and e-mail address. My home address and phone number were accessible from the same record. Two services even had a facility to show a map of my neighborhood and the location of my house in it. The widespread dispersal of information of this sort, without prior consent, is a serious invasion of privacy. In some cases, publishing personal information can be harmful to the individual. For example, battered women have very good reasons to keep present addresses confidential. Because these services gather their data silently, from many sources, they present a real threat to those who require anonymity. In addition, public databases serve as a source for stalkers, scam artists, and junk mailers. Because they potentially support these activities, databases of personal information weaken the social environment of all people on the net inhabit. Below I have listed the URL's for the pages, along with the information that they contain and the contact address for that site. Send mail to the contact address, requesting that they 1) remove you from their database and 2) refrain from including you in the future. Note, the mail you send must contain enough information for the services to know which record to delete. It's best to send the information that the service tracks. Also, be aware that, unfortunately, there is no legal obligation for the companies to remove your name. http://www.four11.com e-mail/phone support@four11.com http://www.whowhere.com e-mail/phone/address delete-entry@whowhere.com http://www.switchboard.com e-mail/phone/address webmaster@switchboard.com (DELETE in the subject line) http://bigfoot.com e-mail/phone/address/map overexposure@bigfoot.com http://www.searchamerica.com This service requires a subscription to view information. Their information page claims that they track names, addresses, and telephone numbers. webmaster@searchamerica.com http://www.abii.com/lookupusa/adp/peopsrch.htm phone/address/map consumerupdate@abii.com Jon Handler jhandler@ils.nwu.edu ------------------------------ Date: Fri, 20 Dec 1996 18:59:06 -0500 From: Matt Blaze Subject: "Cryptography Policy and the Information Economy" draft available RISKS readers may be interested in a draft of my critique of US crypto policy. It summarizes comments I made to a recent meeting of the Computer and Communications Industry Association, and is an updated version of testimony I gave to the Senate Commerce Committee earlier this year. Postscript is at ftp://ftp.research.att.com/dist/mab/policy.ps ASCII text is at ftp://ftp.research.att.com/dist/mab/policy.txt -matt ------------------------------ Date: Sun, 22 Dec 1996 15:53:26 -0500 From: "Christopher Fraser" Subject: Security vulnerability in CERN access protection Some time ago I came across a security vulnerability in the access protection code in CERN httpd. I reported it to CERN last February but I haven't received any reply and the bug is still in the current sources. The bug is interesting because because it highlights a general risk which may be present in other Internet software. CERN accepts access protection as either IP address patterns (such as 192.14.203.*) or as DNS hostname patterns (*.softway.com.au). Because the two share a similar syntax it uses the same code to the comparisons. However, it's entirely possible to construct DNS names that look like IP addresses and match the access protection rules. (I did a quick survey and the only other net software I could find which has the same problem is INN). The bottom line is that if you run a the CERN httpd server as a proxy on a gateway machine and you use IP address patterns to restrict access to the proxy, external attackers can use the proxied services to access internal machines. This vulnerability exists even if your site filters out IP source address spoofed packets and has a paranoid resolver library. I can supply a rough patch to interested parties; please contact me if you would be prepared to test it. Otherwise, a patch will be available from http://softway.com.au/misc/cern.html in the next few days. In the meanwhile, if you are currently using CERN as a proxy on a gateway machine, I would highly recommend using router or host OS IP filtering to restrict access to the proxy service. Additionally you may want to look at newer proxy software, such as Squid, which may or may not be more secure (I haven't looked). Christopher Fraser chrisf@sw.oz.au ------------------------------ Date: Mon, 23 Dec 1996 09:57:30 -0500 (EST) From: Adam Shostack Subject: Re: Emergency Key Recovery and Reconstruction (Perillo, RISKS-18.70) Robert J. Perillo writes of a school that hired a teenager to break in, and points (properly) to the need for key recovery mechanisms for encryption systems. There is, of course, a risk when a backup system is created. The principal and former vice principal were on vacation. (Shouldn't the passwords have been changed?) Another employee had a stroke. So, who present should have been able to authorize emergency key release if the files had been encrypted? The recovery system probably should have a wide notification feature, to help detect misuse, but whom to notify, and would they understand the messages they receive? ------------------------------ Date: Sat, 21 Dec 1996 20:50:58 CST From: "William Murray" Subject: Re: Emergency Key Recovery and Reconstruction (Perillo, RISKS-18.70) Of course, this problem is as old as bank vaults, where the security interest requires that only one person know the combination but other interests require that in the event of his death the vault can still be opened by non-destructive means. I think that a review of the market will demonstrate that "modern security and cryptography" meet this requirement where it exists. The reader who thinks otherwise should compare PGP, intended for personal use, to PGP Business Edition. The former does not include any emergency key recovery while the latter does. Because of my profession, my age, and my failing memory, I choose to use the latter and its features. For the same reason, I choose to use RSA Secure which not only makes my file encryption automatic but also provides emergency key-recovery features. It should be pointed out that these features (unlike proposals by the Clinton administration) provide me with arbitrarily strong protection against abuse by the trustees. They permit me to name an arbitrary number of trustees and require an arbitrary number of them to cooperate to recover the key that I have used. The higher the number that I name, the lower the probability that they will be unavailable when needed. The more of them that I require to participate in the recovery, the lower the probability that the requisite number will behave inappropriately. Two examples may help. For the protection of my file system, I have named two trustees. Since I carry my file system with me, sleep with it under my pillow, and am more concerned about the behavior of my memory than the ethics of my colleagues, either of them acting unilaterally can recover my key. It should also be pointed out that I do not use these techniques for those keys that I use only for communication security. They are restricted to those that I use for file encryption. If I should forget the passphrase used to protect my communication private key, the appropriate remedy is to revoke the old public key, generate a new key pair and publish the new public key. If there are messages that I received but cannot read, they must be resent. Note that using emergency key recovery for communication keys is not secure and may compromise my correspondents. It is at best rude and may violate my obligations to them. Consider by contrast the master key for a major credit card company. This key was generated under rigourous conditions inside a hardware box called the BBN Safekeyper. It is a property of this box that it resists all attempts to remove the private key from the box. Beneficial use of the private key requires possession of the box and all three of the physical keys that fit the three locks on the box. Since the box is subject to physical destruction and since loss of use of the key would be disruptive, not to say destructive, the box published five numbers such that another Safekeyper box could reconstruct the private key from any three of the numbers. Thus, any three of the trustees could prevent the recovery. Of course, the values five and three are arbitrary but they are also illustrative. If 3 out of 5 works for this very sensitive application, it is difficult to imagine an application for which a larger number of trustees are required. A security professional cannot recommend that important keys be stored in any other way. While I may consent to other arrangements, I recommend that important (usually master) keys be stored in hardware dedicated to that purpose with 3 out of 5 emergency key reconstruction. Modern key management enables us to meet all of the security requirements and without creating new problems of their own. Any suggestion to the contrary is, at best misleading. There appears to be an active campaign on the part of the government to pretend that these techniques do not exist and need to be invented. There is also a pretense on their part that the same remedies are necessary and appropriate for communications applications as for file applications. As I have attempted to show, the remedies for one are inappropriate and insecure for the other. Because the government insists upon pretending to an untruth where they must be presumed to know the truth, we should seriously question their motives. William Hugh Murray, CISSP New Canaan, Connecticut ------------------------------ Date: Sat, 21 Dec 1996 10:08:18 -0500 (EST) From: "Daniel P. B. Smith" Subject: Protean documents Roland Giersig's remarks reminded (RISKS-18.70) me of a whole spectrum of issues that arise when one user creates a document and another user *on another computer* tries to edit it. Frequently, a significant portion of the document's state or structure are contained in various preference, configuration, and initialization files, or in the state of the system itself (what fonts are installed, what printer is selected, etc), and surprising transformations occur when the document is transplanted into a different user's computer. The war story: the urgent proposal had to go out immediately; X, who prepared it, was out; Y was frantic because when she opened the fifty-page proposal on her system, everything that should be in boldface was plain, and everything that should be plain was bold. What had happened was that, in some mysterious manner, X's NORMAL.DOT default style sheet had somehow gotten into a state where the normal style had the bold attribute. X had vaguely wondered for months why her word processor "always comes up in bold," but she just typed CTRL-B and went merrily onward. The "bold" attribute applied to text is exclusive-ored with the bold attribute from the style sheet, so everything seemed normal; when she thought she was applying bold, she was really removing it from the text (and allowing the style sheet "bold" to take effect), and vice versa. So all documents created by X had bold and plain swapped when viewed or printed on anyone else's computer. Daniel P. B. Smith dpbsmith@world.std.com [Protean = readily assuming different shapes or roles. (Webster's) PGN] ------------------------------ Date: Mon, 23 Dec 1996 10:12:08 +0500 From: Andrew Koenig Transport Control Technology Ltd. +44 (0)117-9499861 ------------------------------ Date: Sat, 21 Dec 1996 13:01:42 -0800 (PST) From: hbaker@netcom.com (Henry G. Baker) Subject: Re: PCs and configuration management (Epstein, RISKS-18.70) Actually, the computer industry has (up til now) been surprisingly good at keeping model information/configurations consistent. The auto industry, on the other hand, has a dreadful record along these lines. Any car buff knows that auto manufacturers put whatever they had on hand into their cars, and the model number itself is merely one of many clues with which to start your search for the proper replacement part. Depending upon whose stuff arrived that morning, who was on strike that day, the phase of the moon, etc., you may get one of 3-5 different vendor's parts. I've even seen different vendor's parts on different sides of the same car! What's worse: the bracket may be different for each vendor's part, so that nominally interchangeable parts require sheet-metal work because the bolt patterns are different. The worst example I've seen so far in ensuring consistency is Toshiba laptops, where each model number has a different BIOS, _and you aren't allowed to upgrade the disk to a larger disk_ (even it it is a Toshiba disk), because the BIOS won't recognize that size disk. The only way I could get the larger disk to work was to use Norton DiskEdit to set up the volume info to include one volume that the Toshiba BIOS liked, and made sure that that volume was the boot volume. The Toshiba employees who thought up this scheme should be rounded up and shot by the Dilbert patrol. Henry Baker ftp.netcom.com:/pub/hb/hbaker/home.html ------------------------------ Date: Sat, 21 Dec 1996 06:29:39 -0500 (EST) From: "Darrin B. Jewell" Subject: Microsoft documents and Rosetta stones (Giersig, RISKS-18.70) This past summer I was getting increasingly frustrated by users who were sending me e-mail with Microsoft Word ".DOC" files attached to them via MIME encodings. I do not own a copy of Microsoft Word and did not want to purchase one simply so that I could read documents people send to me. Instead, I wanted the specification for Microsoft Word file format so that I would have a Rosetta stone for the documents I wished to read. I contacted Microsoft's customer support and was informed of the following: 1. The specification for Microsoft Word file format is unpublished proprietary information. However, I could download a free reader for Microsoft Word files which would run under one of Microsoft's operating systems. Source code for the reader was not available. 2. I could ask the sender of the message to send me the attachment encoded in Rich Text Format which is the official export format for Microsoft Word documents. The specification for Rich Text Format was publically available from Microsoft. Since I did not own a computer running one of Microsoft's operating systems, I asked Microsoft for the specification for Rich Text Format files. As a computer programmer, this was also a more useful and interesting form of Rosetta stone than a precompiled translating program. I was then directed to the file GC0165.EXE on the Microsoft ftp site, which I was able to download and unzip. (Itself another decoding adventure.) Included was the file GC0165.DOC, a Microsoft Word format file containing the specification I desired. The included README.TXT file contained the following comment in plain ASCII: The GC0165.DOC file included in this compressed file is the Rich Text Format (RTF) Specification version 1.3. The document is in Word 6.0 for Windows format. If you have neither Word 6.0 for Windows nor Word 2.0 for Windows with the 6.0-to-2.0 converter, you will need to call Microsoft Product Support Services at (206) 462-9673 to obtain a hard copy of the document. At this point, I decided it was fastest to have my friend who owned Microsoft Word print out the RTF specification for me. Since this experience, I usually ask people who wish to send me Word documents to send them in RTF format. When I explain to people the RISKS involved in using documents without open standards, I get comments about being ridiculous and pedantic or perhaps a blink and a "So what?" Even though Microsoft Word supports an "official export format", it is clearly not obvious to everyone why it should be used. Darrin ------------------------------ Date: Fri, 20 Dec 1996 18:02:44 -0800 (PST) From: Bob Vaughan Subject: Re: Arrogance of Micro$loth Products (Giersig, RISKS-18.70) My personal experiences have shown that Micro$loth software has some very severe compatibility problems.. - they are not even compatible with themselves. Case in point: I recently designed lighting for a dance show, as part of the process, I needed to create a cue sheet for the stage manager to work from during the rehearsal process. Despite my extreme dislike for Micro$loth in general, I decided that MS Excel for the Mac was the appropriate program to use. I proceeded to input my data for the first act, and saved a copy on the desktop. I continued to input data, and saved a new copy (as a different name) on the desktop, as well as a copy to the CAP server on the nearby Sun workstation. I also printed 2 copies before closing the file. At this point, I had 2 printed copies, and (I thought) 2 online copies, on 2 different servers. I then grabbed a floppy disk, and went to copy the file to it so that I could work on it at the theatre the next day. However, when I went to grab the copy on the desktop (which had been saved not once, but two times!), I found that it did not exist, however the copy from the first act was there (with it's data intact, for the first act only). I then tried the copy stored on the CAP server, only to find that Excel would not open it as a Excel file, no matter how hard I tried. I think the risks are obvious. Another time, I was taking a class at a local community college, as part of the class, we were required to use Word for Windows (unknown version - this was several years ago, and my memory is a bit fuzzy). On several occasions, a file would get saved on a floppy disk, only to find that the file could not be opened by Word for Windows on any machine in the cluster, including the one that it had been created on. (This is typical of my experiences with Micro$loth products in general) As it turned out, I had almost as much knowledge about DOS/Windows as the instructor, and I try very hard to avoid DOS/Windows like the plague. My purpose for taking the class, was to brush up my knowledge of DOS, against the increasing possibility that I would be asked to provide some support for DOS/Windows users (in spite of my hatred of DOS/Windows). As it turned out, the class did not go into DOS at all, instead concentrating on Windows applications, and not at all on the internals of the system itself. The class seems oriented towards future secretarys, and not towards users who wish to learn about how a computer system works. This was in spite of the course description, which implied that the class would be a general purpose introduction to the IBM PC. The Risks? our society is rapidly turning out "trained computer users", who have no idea how the machine works, or even how to restart Windows from a DOS prompt. Bob Vaughan, P.O. Box 9792, Stanford, Ca 94309-9792 techie@w6yx.stanford.edu kc6sxc@w6yx.ampr.org techie@tantivy.net KC6SXC@W6YX.#NOCAL.CA.USA.NOAM ------------------------------ Date: Sat, 21 Dec 1996 20:25:05 -0500 From: "Jonathan I. Kamens" Subject: Re: Arrogance of Micro$loth Products (Giersig, RISKS-18.70) With all due respect, I don't see how bugs in Microsoft products have anything to do with Microsoft's "arrogance." I realize that a large segment of the computer-science community likes to bash Microsoft at every opportunity. A good deal of that bashing may even be deserved. But it is hardly productive or responsible to take every single bug in a Microsoft product as proof that Microsoft is Evil. All that accomplishes is to evoke the "boy who cried wolf syndrome," thus causing real, legitimate complaints about Microsoft to be taken less seriously. The last sentence of your message was rather indicative, I think. "Sorry if this sounds very emotional, but I have already wasted enough precious time with things like these." Yes, your message did "sound very emotional" -- in my opinion, inappropriately so. I'd like to think that the RISKS Digest is above petty anti-Microsoft grand-standing. Jonathan Kamens OpenVision Technologies, Inc. jik@cam.ov.com [So would I. PGN] ------------------------------ Date: Mon, 23 Dec 1996 11:23:11 -0500 From: "Andrew Marc Greene" Subject: Secure passwords on the web? Not at Microsoft! I maintain a web site for the Zamir Chorale of Boston, and so I signed up at the Microsoft Site Builder network web site. Like so many others, it requires a username and password, and I used my standard "insecure" password -- that is, the one that I use at most similar sites. I certainly can't be bothered to remember which password goes with each of fifty web sites that I visit infrequently! Well, I got USPS mail from the Microsoft Site Builder network the other day, encouraging me to visit their web site again -- and, just in case I'd forgotten my username and password, .... [Remainder of item unnecessary for regular RISKS readers.] ------------------------------ Date: 15 Aug 1996 (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) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 18.71 ************************