Subject: RISKS DIGEST 16.77 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 30 January 1995 Volume 16 : Issue 77 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: UK Cabinet Secret on National ID Card Found in Surplus Store (Li Gong) Perils of Call Forwarding (Stephen Thomas, Quentin Fennessy) Deutsche Telekom offices searched (Mich Kabay) My life as "uucp@aol.com" (Uucp@aol.com) Risks of reusing accounts (Charlie Shub) From the cat file (Andrew Koenig) Another stamp machine story (John Kriens) The risks of Risks (Fritz Knabe, Haritini Kanthou) ACSAC '95 Call for Papers and Participation (Marshall D Abrams) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 25 Jan 95 10:02:56 -0800 From: Li Gong Subject: UK Cabinet Secret on National ID Card Found in Surplus Store The Manchester Guardian Weekly (week ending 21 Jan 1995) reported that plans for the UK national ID card system was found in a government surplus store. The second-hand file cabinet was sold for about 35 pounds. It contained memos on investigation into the feasibility of smart-card technology, a detailed card design, as well as cabinet level letters exchanged on this topic. Whitehall has confirmed that the files are authentic. Li GONG Email: gong@csl.sri.com Tel: 415-859-3232 Fax: 415-859-2844 SRI International, Computer Science Lab, Menlo Park, California 94025, USA ------------------------------ Date: Mon, 30 Jan 1995 09:41:22 -0500 From: stephen.thomas@tridom.com (Stephen Thomas) Subject: Perils of Call Forwarding [Plumbing the Depths] I'm sure many eagle-eyed risks readers spotted this one, but just in case, here's an item from an AP story in Sunday's Atlanta Constitution. Stephen A. Thomas, AT&T Tridom, email: stephen.thomas@tridom.com From The Atlanta Constitution, Sunday, January 29, 1995, page D7 Did he steal jobs, thanks to call forwarding? Police say plumber grabbed rivals' calls [Abstracted starkly by PGN] Michael Lasch, a plumber in Levittown, NY, is accused of calling Bell Atlantic to order Ultra Call-Forwarding for at least five of his company's competitors, which enabled him remotely to redirect their calls to his phone. He was charged with theft by deception, criminal attempt, unlawful use of a computer, criminal trespass and impersonating an employee. The scam was detected when a customer complimented another firm on work performed over Christmas weekend -- when in fact no one had been working! [The WRENCH that stole Christmas?] [Also noted by "Whittle, Jerome SMSgt" and Quentin Fennessy , from whom I include the following excerpt. PGN] ------------------------------ Date: Sun, 29 Jan 1995 12:30:47 -0600 From: Quentin Fennessy Subject: Phone number hijacking with Bell Atlantic ultra-forwarding [...] There is nothing new about this crime - except the use of a new medium to hijack a channel of communications. The risks are obvious - as more such services are available without verification the more this crime can occur. I suppose that if Lasch were more sophisticated he could have kept up his scheme for much longer. For example, if the ultra-forwarding were flexible enough he could enable it for the coldest days, in order to fill up his queue with work orders for frozen pipes, and then disabling the forwarding while he completed the jobs. Quentin Fennessy ------------------------------ Date: 27 Jan 95 10:50:59 EST From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Deutsche Telekom offices searched From the Reuters newswire (95.01.25 @ 11:36 EST) via CompuServe's Executive News Service: Deutsche Telekom Offices Searched in Fraud Probe, by William Boston BONN, Jan 25 (Reuter) - Police searched offices of Deutsche Telekom AG on Tuesday to determine whether staff at the German state telephone monopoly had withheld proof of computer hackers tapping into private phone lines to call foreign sex hotlines. Juergen Froehlich, chief prosecutor in Cologne, said in a statement that police went through Telekom offices in Bonn, Cologne and Duesseldorf as part of an investigation into a gang of hackers. The author continues with the following key points: * Legal authorities are investigating the possibility that D.T. employees concealed data on stolen phone services. * Over 2M D.T. clients have complained about fraudulent phone calls charged to their accounts over the last 30 months. * D.T. officials deny that its customers paid for any fraudulent calls, explaining that the criminals placed their calls from accounts obtained using false names. M.E.Kabay,Ph.D., Director of Education, NCSA (Carlisle, PA) Mgmt Consultant, LGS Group Inc. (Montreal, QC) ------------------------------ Date: Sat, 28 Jan 1995 18:45:29 -0500 From: Uucp@aol.com Subject: My life as "uucp@aol.com" America Online allows its user accounts to specify up to five "screen names", which uniquely identify the user. AOL screen names consist of a capital letter followed by two to nine alphanumerics or spaces. The screen name is not case-sensitive, so "MR SMITH" and "Mr Smith" refer to the same account, and the AOL software forces uniqueness on new names by appending digits to the end of the name. AOL accounts can also send and receive Internet e-mail. AOL converts its screen names to Internet-style addresses by dropping all spaces and appending "@aol.com", so our "Mr Smith" becomes "mrsmith@aol.com" to the outside world. Which is where I come in. I was trying to come up with a unique screen name that did not end in randomly assigned digits -- AOL's membership stands at 1.5 million users, each of whom can reserve up to five names, so most common English words and names are already taken. Idly searching for a name, I requested "root". (I always put this down as my first choice when requesting a new account. It never hurts to ask.) The AOL software politely informed me that this name was taken, and said the same when I requested "postmaster", "webmaster", etc. In some cases it suggested an alternative like "webmast236", and in others it simply said "That name is taken." Then I requested "uucp". And the software asked me to enter my new password. * Since then I've been getting a lot of strange e-mail, to put it mildly. Much of it is private correspondence from external addresses to accounts on AOL, or vice versa, that has been Cc:'d to uucp. (I don't know why. Is this happening due to user ignorance or carelessness, or is it the behavior of the mail software?) In no case so far has the sender suspected that "uucp@aol.com" is a live human being. The RISK here is the assumption that "uucp" (or, for that matter, "root") is a trusted e-mail address on the remote machine. The only required e-mail address in RFC 822 is "postmaster" -- there is no requirement that the remote machine use the UUCP transport mechanism, the UNIX operating system, or that any e-mail address other than "postmaster" route e-mail to the system administrator. ("Postmaster@aol.com" does route e-mail to a person responsible for AOL's mail system, in compliance with RFC 822.) AOL reserves certain screen names to prevent this kind of confusion, but "uucp" was not one of the reserved names. (Neither was "nuucp", if you were curious -- I've reserved that one too. I think I can retire both addresses permanently by deleting the screen names from my account, but I plan to make certain before doing so.) "Root@aol.com" and "webmaster" are already in use, but I can't say *who* is using them. Of course these RISKs apply to any site, not just to AOL -- any site could have a user account named "uucp" and still be RFC 822 compliant. But as the net grows, and incorporates more and more diverse machines, the RISK becomes more dangerous. Don't assume that mail addressed to "uucp" or "root" on a remote machine is going to a trusted recipient, because for at least one large site this assumption isn't true. Scott Forbes MSForbes@aol.com ------------------------------ Date: Wed, 25 Jan 1995 23:47:46 +0700 From: cdash@ludell.uccs.edu (Charlie Shub) Subject: risks of reusing accounts Two years ago, i was on sabbatical at a large university, and picked up some support by teaching a course. Their division of computing services managed many computing accounts, and had a pretty reasonable scheme for class accounts. They used a 3 letter followed by 3 digit account names. The first two letters denoted the department, and the third letter was a for the first course, b for the second course, etc. 000 was always the instructor's account and 001 was student 1, 002 student 2, etc. A reasonably sane idea. I would guess that at the end of each semester they cleaned student accounts by deleting all files and reinserting initialization files. They would then generate new passwords for all accounts each semester. What is the risk? accounts may have state data that does not appear in the account or that is not normally cleansed. The course i was teaching was on a machine i did not use for my personal work, so i had set up automatic mail forwarding to my machine here that I normally read mail on (by telnet from there when i was there). The between semester cleansing algorithm did not reset that forwarding address. Finally, the 5th course in the department again used that same machine, so account cse000 became the instructor's account. That instructor has apparently given the students a "use e-mail" assignment, and did not test the system with a self mailing. Since the forwarding is still in effect, I have been receiving electronic mail intended for this instructor for the past few days. I thought of sending him/her email to let him/her know about this, but realized that such mail would immediately be forwarded to me. I thought of replying to the students, but if they are just learning about computers, that would also be fruitless. I thought of logging into the account to unset the forward, but the new instructor has obviously changed the password. I suppose I could have chosen to just wait until some interested party finds this in risks, or watch from the sideline until confusion reigns. I believe I have identified the instructor, and have sent her email. A blind copy of this note to risks is being sent to a friend at that institution who will, no doubt, follow up with the instructor and keep me (and perhaps risks readers) posted on how this shakes out. charlie shub cdash@cs.colorado.edu -or- cdash@colospgs (BITNET) (719) 593 3492 (fax) 593-3369 ------------------------------ Date: Thu, 26 Jan 95 16:56:42 EST From: ark@research.att.com Subject: From the cat file This morning I was sitting at my home terminal, reading mail. I got up for a few minutes. When I returned to the terminal, the screen showed a partial reply to the last message I had been reading. It looked something like this: From: ark@research.att.com To: sender@machine.com Subject: edbone 2222222222222222222222222222222222222222222222222222222222222222222222 It didn't take me long to figure out what had happened. This particular terminal has function keys that can be set to store strings. Once upon a time I often used a machine named `redbone,' the name of which was therefore stored in that function key. Sitting on the table, next to the keyboard, was one of my two big, fluffy cats. She had evidently pressed that function key and the mailer interpreted the `r' of `redbone' as a request to reply to the message. After that, she must have spent some time sitting on the `2' key. Oh well, at least she didn't try to eat the mouse. --Andrew Koenig ark@research.att.com ------------------------------ Date: 30 Jan 1995 18:00:26 -0500 From: jkriens@cc.bellcore.com (kriens,john) Subject: Another stamp machine story My stamp machine story is similar to that of Jonathan Kamens in RISKS-16.76 in that the machine was programmed to keep the person using the machine from losing money. It is different in that it let me get into a situation where I could neither buy the stamps I wanted, nor could it give me my money back. There is a stamp machine in the basement of one of the buildings in our corporate campus, we also have a U.S. Post Office in our backyard, but if you're lazy or in a hurry, it's simpler to use the machine. Anyway, I wanted to buy a book of stamps (back when they were still a bargain at $5.80 for the book of 20). I decided to go to the stamp machine. Now, I had $6.00 with me--a five and a one. There was a sign on the machine saying that the machine would give back no more than $.50 in change. I took this sign to mean that I could put in more money if I wanted, but the most change I could get for overpayment would be $.50. Anyway, for some reason, I decided that I wanted to get a quarter back, rather than two dimes. I would put in $6.05, get $5.80 worth of stamps, and get a quarter back. Most candy vending machines will let you do this, but you have to put your change in first, before the bills--otherwise they know that you're overpaying and won't let you put the coins in. I started off with a nickel. I then put the $1 bill in. So far, so good. I then attempted to put the five in. The machine just wouldn't accept it. I can't remember what message the machine gave me, but it was not enlightening. After trying 5-10 times to get it to take the bill, I reached the conclusion that it just wasn't taking five dollar bills today (since my bill was in pristine condition). It also wouldn't let me get back the money I'd already put into the machine. Since I was stuck with either losing my money or getting change and hoping I would finally get my stamps, I left the machine and dashed upstairs to our credit union to get change for the five. Luckily, there was no line, so I got my five $1 bills and ran back downstairs. The money was still registered in the machine, so I proceeded to feed my $1 bills in. Everything went fine until I got to the fifth bill--which the machine refused to take. Once again, the bill was in perfect shape. After trying a bunch more times, I realized that I would need exact change, so I walked down to the change machine in one of the break rooms to get the bill broken into coins.. Unfortunately, it took too long to get the coins and I arrived back at the machine just in time to see it finish telling me I had taken too long and reset itself, removing all traces of my money from the display. As you have probably deduced by now, the machine had been programmed to not allow a person to put more than the next highest dollar amount into the machine from the purchase price of the stamps. Since all of the denominations of stamps were between $(X).50 and $(X+1).00 [books of $.29 stamps were $2.90 and $5.80 and post card stamps were $1.90 or $3.80], the machine assumed that anyone putting in more than the next dollar would risk losing money--something they *clearly* would not want to do, since they would lose money. (Never mind that they would also lose the money they'd put in up to this point since once the bills go into the machine they don't come back out.) The sign about getting a maximum of $.50 back was misleading since the machine gave no opportunity to lose that much. Luckily the Post Office refunded my money without any hassle, but I still wish whoever programmed the machine hadn't thought they were being so damn clever. -John Kriens jkriens@cc.bellcore.com ------------------------------ Date: Mon, 23 Jan 95 17:13:13 +0100 From: Fritz Knabe Subject: The risks of Risks As a frequent reader of the RISKS forum, I was very interested when "Computer-Related Risks" (our esteemed moderator's new book) was reviewed here. Using the information from the review, I faxed an order to ACM. Two months later, with no book, I discovered that ACM had debited my credit card for $34.50, rather than the $22.25 + shipping that I was expecting. It seemed that not only did I not have the book, the book I didn't have wasn't even the one I wanted. I called ACM and discovered that whoever processed my order completely ignored the title and author information in my fax and went right for the 6-digit order number, which it turns out was incorrect. (Interestingly enough, the order number identified a book on software quality.) I hadn't received the wrong book because it was out of stock (I had received no notification of this, either). The lessons? Overworked order entry people will enter an order number and simply ignore the accompanying description, even though the description is much more likely to be correct. And next time I'll be sure to check the order number directly with ACM, or leave it off. Fritz Knabe knabe@ecrc.de ------------------------------ Date: Wed, 25 Jan 95 12:18:23 EDT From: Haritini Kanthou Subject: The risks of Risks (Fritz Knabe) Thank you for bringing to our attention the fact that in one of the ads in CACM, the order number for Peter Neumann's Computer-Related Risks was incorrectly cited as 706943. The correct number is 704943, at $22.25 plus shipping for ACM members or $24.75 plus shipping to nonmembers. [The incorrect number was first found in the original press release from ACM, and it got propagated to various other places. PGN] Haritini Kanthou, Member Services Mgr. acmhelp@acm.org ------------------------------ Date: Fri, 27 Jan 95 23:25:07 EST From: abrams@mitre.org (Marshall D Abrams) Subject: ACSAC '95 Call for Papers and Participation CALL FOR PAPERS AND PARTICIPATION 11th Annual Computer Security Applications Conference December 11-15, 1995 New Orleans, Louisiana The Conference The phenomenal growth of the Internet is threatening our very notion of privacy and property. Information networks and computers are routinely processing private, proprietary, sensitive, classified, and critical information. The Internet has created an addiction to information and instantaneous information exchange in the military, government, and private sectors. Computers are making decisions ranging from the mundane to life threatening. To provide protection to this information, the information technology community must: o Develop methodologies and tools for designing systems capable of protecting the sensitivity and integrity of information, and assuring that expected services are available when needed. o Design safety-critical systems such that their software and hardware are not hazardous. o Develop methodologies and tools capable of assuring that computer systems accorded trust are worthy of that trust. o Build systems of systems out of components that have been deemed trustworthy. o Build applications on evaluated trusted systems without compromising the inherent trust. o Include computer security in enterprise modeling and reengineering. o Extend computer security technologies to specifically address the needs of the civil and private sectors. o Develop international standards for computer security technology. For the past 10 years the Annual Computer Security Applications Conference has been helping the IT community meet these challenges by providing a forum for information exchange that is unsurpassed. The Conference will explore a broad range of technology applications with security and safety concerns. Technical papers, panels, vendor presentations, and tutorials that address the application of computer security and safety technologies in the civil, defense, and commercial environments are solicited. Selected papers will be those that present examples of in-place or attempted solutions to these problems in real applications; lessons learned; and original research, analyses, and approaches for defining the computer security issues and problems. Of particular interest are papers that present descriptions of secure systems in use or under development, presenting general strategy, methodologies for analyzing the scope and nature of integrated computer security issues, and potential solutions. Papers will be judged for best paper awards. A prize will be given for the Outstanding Conference Paper and the Best Student Paper. For the Best Student Paper, expenses to attend the conference will also be awarded . Panels of interest include those that present alternative or controversial viewpoints or those that encourage lively discussion of relevant issues. Panels that are simply a collection of unrefereed papers will not be selected. Vendor presentations of interest should emphasize innovative product implementations, especially implementations involving the integration of multiple products. Vendor presentations that simply describe product features will not be selected. Areas of Interest: Security in Enterprise Modeling and Reengineering Trusted System Architectures and Technology Encryption Applications (e.g., Digital Signatures) Certification, Evaluation, and Accreditation Application of Formal Assurance Methods Trusted DBMSs, Operating Systems, and NetworksSecurity Policy and Management Issues Electronic Document Interchange Open Systems and Composed Systems Software Safety Analysis and Design Risk/Hazard Assessments AIS Security Tools Instructions for Submissions: We provide blind refereeing of papers and ask that you put names and affiliations of authors on a separate cover page only. Substantially identical papers that have been previously published or are under consideration for publication elsewhere should not be submitted. Panel proposals should be a minimum of one page that describes the panel theme and appropriateness of the panel for this conference, and should identify panel participants and their respective viewpoints. Send 5 copies of your completed Papers and Panel proposals to Dr. Gary Smith (papers from Europe should be sent to Klaus Keus) by May 31, 1995. For panel/forum preparation instructions, please contact Jody Heaney at (703) 883-5837 or via e-mail at heaney@smiley.mitre.org. Send five copies of your vendor presentation proposal to Steve Rome. Vendor presentation proposals should include an abstract that describes the product and example applications. Send one copy of your tutorial proposal to Daniel Faigin. It should consist of one- to two-paragraph abstract of the tutorial, an initial outline of the material to be presented, and an indication of the desired tutorial length (full day or half day). Electronic submission of tutorial proposals is preferred. Authors will be required to certify prior to June 30, 1995, that all necessary clearances for public release have been obtained; that the author or qualified representative will be presented at the conference to deliver the paper, and that the paper has not been accepted or previously published elsewhere. Authors will be notified of acceptance by August 1, 1995. Camera-ready copies are due not later than September 30, 1995. Instructions to Students: Student papers must be authored 100% by students; no faculty authors are permitted. Send 5 copies of student papers to Dr. Gary Smith; please identify your paper as "Authored by Student." Contact Ravi Sandu, Student Paper Award Chair, to ensure that your paper is considered for the Best Student Paper Award. This award includes expenses to allow the student to travel to the conference and present the paper. Contact Information Send your papers to: Dr. Gary Smith Technical Program Chair ARCA Systems, Inc. 8229 Boone Blvd., Suite 610 Vienna, VA 22182 (703) 734-5611 smith@arca.va.com or Klaus J. Keus BSI Bundesamt fuer Sicherheit in der Informationstechnik Kessenicher Str. 216 53129 Bonn Germany Phone: Germany-(0)228-9582-141 Fax: Germany-(0)228-9582-455 e-mail: keus@bsi.de Send tutorial proposals to: Daniel Faigin Tutorial Program Chair The Aerospace Corporation P.O. Box 92957, MS M1/055 Los Angeles, CA 90009-2957 (310) 336-8228 faigin@aero.org For information about Student Paper contact: Ravi Sandhu Student Paper Award Chair George Mason University ISSE Department, Mail Stop 4A4 Fairfax, VA 22030 (703) 993-1659 sandhu@isse.gmu.edu Send vendor proposals to: Steve Rome Vendor Track Chair NSA, V23 9800 Savage Rd. Ft. Meade, MD 20755 (410) 684-7374 romes@romulus.ncsc.mil Videos Still Available! Video tapes of the 1989, 1990, 1992, 1993, and 1994 Distinguished Lecturers are still available. The titles and lecturers are: 1994 Donn Parker "Computer Loss Experience and Predictions" 1993 H. O. Lubbes, "COMPUSEC, A Personal View" 1992 James P. Anderson, "Computer Security Myths and Mythtakes" 1990 Dorothy Denning, "The Data Encryption Standard: Fifteen Years of Public Scrutiny" 1989 Stephen T. Walker, "INFOSEC: How Far We Have Come! How Far Can We Go?" The price for each tape is $17.00. An additional $5.00 will be charged for foreign orders for postage. Checks should be made out to Applied Computer Security Associates (ACSA). Send check to Dr. Marshall Abrams, 2906 Covington Road, Silver Spring, MD 20910. Please indicate which tape you are ordering. Conference Proceedings Some copies of the 1992 and 1994 proceedings can still be purchased through Ron Ross for $25 each. Contact him at The Institute for Defense Analyses, 1801 N. Beauregard Street, Alexandria, VA 22311, (703) 845-6617, e-mail: rross@ida.org. For 1991 & 1993 Proceedings, contact the Computer Society Press by dialing 1-800-CS-BOOKS or (714) 821-8380. The non- member price is $80, the IEEE member price $40. Mailing List To be added to the Annual Computer Security Applications Conference mailing list to receive future conference announcements, please send Name, Company, Address, City/State/Zip, Country, and e-mail address to Vince Reed, Publicity Co-chair , The MITRE Corporation, 1500 Perimeter Pkwy., Suite 310 , Huntsville, AL 35806, phone: (205) 830- 2606, fax: (205)830-2608, e-mail: vreed@mitre.org Sponsored by Applied Computer Security Associates in cooperation with IEEE Computer Society Technical Committee on Security and Privacy, and ACM Special Interest Group on Security, Audit and Control. Marshall D Abrams telephone 703.883.6938 Information Systems Security Division secretary 703.883.5900 The MITRE Corporation, M/S Z202 facsimile 703.883-1397 7525 Colshire Drive, Mc Lean, VA 22101-3481 ------------------------------ Date: 22 December 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. Risks can 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) 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. CURRENT ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 15, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. ------------------------------ End of RISKS-FORUM Digest 16.77 ************************