Text File

Subject: RISKS DIGEST 17.04 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Thursday 6 April 1995 Volume 17 : Issue 04

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: Thoughts on SATAN, Michelangelo and Crack (Tom Perrine) A possible "solution" to Internet SATAN: Handcuffs () Make a Call, Turn Off the Power (Mike Winkelman) Boeing 777 has dainty feet (Nathan Myers) Risks of HCI designed by non-typist (Pete Mellor) Endless loops in Voice Mail (Dick Mills) Computer will control Nick Ingram's execution (Mike Wilson) "Airport Vending Machine Sells Computer Programs" (Barry Jaspan) Computer Security's an Oxymoron (Edupage) Re: Complexity (Stephen L Nicoud) RISK of webpage rating system (Joan Combs Durso) Chunnel as a Theme Park (Re: Ghost trains) (A. Padgett Peterson) Insecurity over ATM security (Jon Green) Safeware: System Safety and Computers (Nancy Leveson) InfoWarCon '95, First Call for Papers (Winn Schwartau) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Tue, 4 Apr 95 21:40:39 PDT From: Tom Perrine <tep@SDSC.EDU> Subject: Thoughts on SATAN, Michelangelo and Crack

Well, here it is, only 10 hours until the Internet As We Know It will grind to a halt. Of course, the Imminent Demise of the 'Net has been predicted before. In fact, this will be at least the fifth time that I have personally witnessed such mass hysteria and overzealous concern over the "safety and integrity" of the Internet.

There has been so much hype over the release of SATAN, including articles in the New York Times, fer cryin' out loud, that entirely too many people have no idea what is going on, but They Are Sure That Truly The Sky Will Fall.

It is very strange, and somehow wonderful, that our society finally has enough people with some knowledge of the Internet, that they could even care about the integrity of the Internet. It is also, however, sad that they do not understand that thing which they use every day, and have come to depend on so much.

What is the truth behind the hype? Will SATAN be the ultimate "cracking" tool? Is it the network equivalent of an unstoppable skeleton key?

Of course not. SATAN is nothing more than a software implementation of a checklist of well-known flaws in the design and/or implementation of the UNIX operating system and its network servers, and Internet protocols. There is nothing in SATAN that hasn't been seen in at least a dozen intrusion attempts in the last year. The holes examined by SATAN have been known to the cracker community for years in most cases.

Does this mean that the release of SATAN is unimportant? That all the hype and publicity has been a mistake? That there is no reason to worry?

Again, of course not. After the Michelangelo virus media "event" of a few years ago, the computer world breathed a huge sigh of relief. The predictions were that between 15 and 50% of the world's personal computers would be destroyed by Michelangelo. This obviously didn't happen. True, most estimates of infection rates were obviously out of line. But a significant number of companies and individual users reported that due to the media blitz, they now took virus protection seriously, and almost everyone admitted that they scanned their systems for virii in the weeks before Michelangelo was due.

SATAN will be important for the same reason that Michelangelo and Crack have been important: they have raised the issue of computer security in a way that cannot be ignored, and they have given harried system and network administrators some of the same tools already in use by cracker.

Sites that used to be able to ignore the risks of connecting to the Internet, who believed that they were immune, too low-profile, of just didn't understand now know that they *must* take steps to protect themselves.

With the certain knowledge that SATAN (and other tools) are out there, being susceptible to well-known attacks clearly shows a lack of "due diligence", which a term which courts and juries seem to understand.

Now that SATAN is out, any commercial site that is cracked may find itself involved in legal action from its users and customers.

There is considerable belief (one might also suggest consensus) that the availability of Crack has forced sites to use non-dictionary passwords. Since Crack became available, the "cracking" of passwords from stolen password file has almost completely disappeared from the Internet.

SATAN will level the playing field, as now system administrators who things to do other than write custom cracking packages will have the same tools as the "black hats".

I hope that the release of SATAN will encourage vendors to increase the security of their shipped products, and raise the level of security awareness throughout the Internet. Just by existing, it will, after a time, improve the integrity of the 'Net as we now know it.

But for the next few weeks, "let's be careful out there."

Tom E. Perrine (tep@SDSC.EDU), San Diego Supercomputer Center +1.619.534.510 http://sdsc.sdsc.edu/SDSC/Staff/tep FAX: +1.619.534.5152

------------------------------

Date: Wed, 05 Apr 95 10:00 xxT From: [address withheld by request] Subject: A possible "solution" to Internet SATAN: Handcuffs

The authors of the recently released SATAN package for probing Internet sites have shown a level of amorality that should gladden the hearts of the National Rifle Association and arms merchants around the world. By close analogy, SATAN's parents' attitude appears to be that it's perfectly OK, perhaps even admirable, to go from house to house without permission trying each door and window to see if it's unlocked, or perhaps not locked securely enough. If caught inside, the intruder would of course claim he or she was just performing a "security check", and gee whiz, that homeowner REALLY should buy a better lock! Bull****. That sort of argument wouldn't wash with unauthorized residential probing/entries/burglaries, and it shouldn't be acceptable for such unauthorized activities when directed against computer systems either. Up to now, most system administrators have tended to take a fairly permissive attitude towards hacking probes/attacks--at least the first time. Usually the farthest they go is to warn the offending users and/or system administrators at the site originating the attack, and let it go at that. The time has come for this attitude to change. It's time for it to be made clear in no uncertain terms that any unauthorized probing cases will be immediately turned over to law enforcement for appropriate criminal and/or civil actions whenever possible. A variety of laws would appear to make it illegal to use SATAN or similar tools against a site without that site's permission. Most likely there are a number of cyber-lawyers who could do quite well specializing in this area. Where attacking users can be identified, enforcement can be directed towards them. Where sites are unable or unwilling to cooperate in identifying the user, then action may have to be taken against sites where attacks originated as well. It is perhaps unfortunate that this sort of "no more excuses" policy will probably net a large number of rather ignorant users who run tools like SATAN "for fun" while oblivious to the logging, tracking, tracing, and other countermeasures that exist against it. But that's the price they'll have to pay for playing with powerful tools left laying around by amoral software engineers. Playtime is over, kiddies.

[Don't forget, SATAN runs as root -- although that is not necessarily an obstacle for many folks, and some of it can be hacked to run unprivileged. But breaking root in the first place falls into the "unauthorized" category. PGN]

------------------------------

Date: Wed, 5 Apr 1995 16:56:47 -0400 From: mlwinkelman@dow.com (Mike Winkelman) Subject: Make a Call, Turn Off the Power

I suppose I shouldn't be surprised, but the power went out for 17,000 here in our small town (38,000) last week. The local newspaper first reported that the power company didn't know why it went out, but that it "may be related to someone digging in their back yard". A week later they fixed the blame. A phone call (by the power company), supposedly to one substation, (completely automated judging by the tone of the article) went instead to a different substation (for unexplained reasons) and shut that substation down. It was down for 1.5 hours.

The risks?? Just think of a few well placed calls by non-power company people to major metropolitan areas in the dead of night if they have similar systems.

------------------------------

Date: Tue, 4 Apr 1995 23:38:16 -0700 From: ncm@netcom.com (Nathan Myers) Subject: Boeing 777 has dainty feet

I have heard recently that the new Boeing 777 jetliner, described in recent news reports as "skating through the approval process", has a little problem that might be interesting to RISKS readers.

It seems that an important part of the landing gear is too weak, and will get "used up" (through metal fatigue), and need to be replaced annually. While this is probably not a safety problem, it's an extra expense (frequent inspections and replacements) and an embarrassment.

Unfortunately, fixing it isn't just a matter of making the part stronger; it would then be bigger and heavier, affecting fit, balance, and nearby parts. This sort of problem is familiar in the "shakeout period" of all previous jetliners, but it's surprising that it showed up so late in the approval process. (A previous 7?7 has a nonlinearity in the landing gear linkage that caused an oscillation when trying to close the doors; it was fixed by an appalling hydraulic "patch" that cancels feedback during the nonlinear portion of the cycle.)

How did this mistake get all the way through Boeing's legendary engineering process? The 777 is the first commercial Boeing to have been modeled entirely on computer before construction. Apparently the part is precisely a factor of two weaker than it should have been. Does this smell like a structural model entry error? I have been unable to find out more about the source of the error, and would welcome more detailed information.

Maybe the RISK is in streamlining your engineering process so well, and eliminating so many of the more common mistakes that would have caused delays, that you are already getting final FAA approval before the booboos that only time can reveal are noticed. Or maybe the RISK is just that better communications can leak word of embarrassments few would have known about otherwise.

------------------------------

Date: Tue, 28 Mar 95 15:45:14 BST From: Pete Mellor <pm@csr.city.ac.uk> Subject: Risks of HCI designed by non-typist

The Management and Administrative Computing Initiative (MACI) is an attempt to get all universities in the UK to use the same computer package for their administrative operations. (In fact, it has been found necessary to define four "families" of universities with similar approaches, and design a package for each family.)

The requirements specification, design and gradual implementation of the MAC packages is proceeding. The following anecdote might amuse readers of RISKS who take an interest in Human Computer Interface design.

The part of the MAC package which deals with job applications in a certain university (which shall remain nameless) has had an interesting little "feature" incorporated into its HCI by one of the implementors (who has since moved on to pastures new). To save the effort of the typists in keying data into a name or address field, he arranged that letters could be typed in upper or lower case anywhere, and on input the case would be changed so that initials and the first letter of each word would be capitalised, and the remainder put into lower case.

To a two-fingered typist like him, this probably seemed like a great labour-saving idea. For a trained touch typist (such as my informant) it saves nothing, of course. Not only that, but responses to applications are now being sent to "Dr. B. O'malley, University Of Newcastle-Upon-Tyne".

Lessons for HCI design would seem to be:-

1. Write a specification.

2. Get someone else to read it before implementation.

3. Better still, get the feedback from the use of a prototype.

4. If you want to know the user's requirements, ask the user!

The costs of getting a different person to remove the feature, and of cleaning up the database, are still being counted!

Peter Mellor, Centre For Software Reliability, City University, Northampton Square, London Ec1v 0hb +44 (171) 477-8422, Fax.: +44 (171) 477-8585,

------------------------------

Date: Tue, 04 Apr 1995 11:53:17 -0400 From: rj.mills@pti-us.com (Dick Mills) Subject: Endless loops in Voice Mail

I just called someone at "XX" Software Inc. He told me he would be at extension 126. Here's an abbreviated transcript of what I heard.

IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [126] SORRY, THERE IS NO EXTENSION 126. IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [wait] IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [Hmmm. It is in a loop. What if I dial '0'?] HI THIS IS ANN. I'M NOT IN THE OFFICE TODAY. PLEASE LEAVE A MESSAGE AT THE SOUND OF THE BEEP. BEEP. [Hmm. Didn't work. Hang up and dial again.] IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [wait] ONE MOMENT PLEASE, YOUR CALL IS BEING TRANSFERRED TO AN OPERATOR. HI THIS IS ANN. I'M NOT IN THE OFFICE TODAY. PLEASE LEAVE A MESSAGE AT THE SOUND OF THE BEEP. BEEP. [Sigh, hang up]

So what's the risk? We have been conditioned to think of telephones as non-programmable devices. So when we purchase a new phone system which is programmable, we may neglect applying the same quality assurance to phone programming as we [hopefully] do to normal software.

A good way to avoid the trap is to inventory your belongings. Which things do you own that are actually dumb, purportedly dumb, or traditionally intelligent? Presumably you know how to deal with the first and last. Now think carefully about the middle ones. Are you treating them with proper lack of trust?

------------------------------

Date: Thu, 6 Apr 1995 11:25:07 +0100 (BST) From: "Mike Wilson, ICL Medical Portfolio" <mrw@oasis.icl.co.uk> Subject: Computer will control Nick Ingram's execution

>From "Today" newspaper, London, England, 6 April 1995:

Nick Ingram's execution will be controlled by a computer. It is the first of its kind and follows a series of electric chair bungles where condemned men survived a manually controlled surge. Three executioners will each push a button to activate the computer but only one is "live", leaving none of the trio knowing if he started the deadly process. The computer will then take 30 seconds checking every connection to Ingram's head, legs and arms and, if there are no problems, will send 2,000 volts slamming into his body for four seconds. It then switches the current to 1,000 volts for seven seconds and 208 volts for two minutes. Throughout the execution, the computer's systems monitor the current, making sure there is no drop in power. Five minutes from when the current is stopped, a doctor will pronounce the Briton dead.

The risks are horrifying.

Mike Wilson mrw@oasis.icl.co.uk ICL Medical Portfolio, Kings House, Kings Road, Reading, RG1 3PX, UK

[Sure gives a new meaning to volt-tolerant systems. PGN]

------------------------------

Date: Tue, 4 Apr 1995 17:13:11 -0400 From: "Barry Jaspan" <bjaspan@cam.ov.com> Subject: "Airport Vending Machine Sells Computer Programs" (AP)

An recent AP article describes a prototype vending machine installed at the Raleigh-Durham International Airport. The machine sells shareware. A customer inserts a floppy disk, selects a program, inserts money, and out pops the disk with the software installed.

I suppose that the RISKS are really no different than when retrieving software over the network, and practically is not as big a problem since far fewer people will use it. Somehow, though, the thought of a row of machines at which I can buy Camels, Coke, Snickers, and Tetris makes me shiver.

Barry Jaspan

------------------------------

Date: Tue, 4 Apr 1995 23:47:21 -0400 From: info@ivory.educom.edu (Edupage) Subject: Computer Security's an Oxymoron (Edupage 4 April 1995)

Computer break-ins are still on the rise, often accompanied by significant financial losses. The Computer Emergency Response Team's manager says the number of reported violations was 130 in 1990, 800 in 1992, 1,300 in 1993 and 2,300 in 1994. A 1994 survey by Ernst and Young of more than a thousand companies showed 20% reporting financial losses as a result of computer break-ins. An earlier study by USA Research cited losses of $164 million in 1991 due to unauthorized intrusions. (Technology Review, April 1995, p.33)

------------------------------

Date: Thu, 6 Apr 95 10:38:09 PDT From: Stephen L Nicoud <stephen.nicoud@boeing.com> Subject: Re: Complexity (English, RISKS-17.03)

(it could be argued, for example, that air travel is currently too safe, because the close attention to safety raises the cost of short-haul flights and encourages people to drive instead)

Citing Paul Russell (Chief Engineer, Boeing Airplane Safety Engineering) an August 18, 1994 article in The Aviation Daily reported that the "jet transport accident rate plummeted between 1959 and 1975 but has been fairly flat since then...".

"With more and more traffic looming in the future ..." there is "a projection of one jet transport hull loss per week by the year 2010".

A hull loss is airplane damage which is substantial and beyond economic repair.

Stephen L Nicoud <Stephen.Nicoud@Boeing.Com> [Disclaimers...]

------------------------------

Date: Wed, 5 Apr 1995 14:48:00 -0400 From: jcd2@psu.edu (Joan Combs Durso) Subject: RISK of webpage rating system

The only objection I can think of to the proposed system of sorting possibly objectionable material according to "over13" and etc is this: one of the current justifications for NOT regulating the adult material is that it takes some looking to find it. The proposed rating system would seem to make such materials readily identifiable via searching, thus pointing out for all the world the locations of this material, and making it easier for kids using unrestricted browsers to find.

Joan Combs Durso, Penn State Great Valley

------------------------------

Date: Tue, 4 Apr 95 14:29:01 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Chunnel as a Theme Park (Re: Ghost trains, Wodehouse, RISKS-17.03)

This happened to my wife a couple of weeks ago & she said some passengers became somewhat frantic looking for rising waters - officials did come around giving out coupons for a half price repeat trip if taken within two months - Universal Studios did something similar when it opened and the Jaws ride did not work.

The real RISK will occur if (when) a driver ignores a real signal.

Padgett

------------------------------

Date: Thu, 6 Apr 1995 16:20:59 +0100 (BST) From: jonsg@diss.hyphen.com (Jon Green) Subject: Insecurity over ATM security

My local branch of the Midland Bank has just upgraded its ATM (automatic teller machine - hole in the wall cash dispenser). The old unit had a central keypad, and a green screen with a filter which restricted the useful angle of vision to about ten degrees either side of dead-in-front. The screen was positioned to the left of the machine, making it easy to block almost the whole arc and it was not readable from more than about 5m away. You could prevent all but the most persistent shoulder-hanger from seeing your PIN being entered, and your balance when it came up on the screen, by interposing your body.

The new box features a nice bright colour screen and flashing lights to point you to the next bit of the ATM to look at (card slot, cash slot and so forth). Unfortunately, the nice bright screen is visible clearly from about 10m or more away, over an approximate 90 degrees of arc at least. To make things worse, the keypad is placed to the left of the machine, so that 90% of the population is left to dial in their PIN slowly and laboriously with their wrong hand. Oh, and the keys are so stiff that anyone standing to the right of the machine could not hope to avoid being able to read off the PIN as it is stabbed in. The final insult is that - like former machines from the same bank - the balance is shown on-screen only. No option to print it out instead.

What a disaster! The RISKS abound - PINs are highly visible from an adjacent position, all on-screen transactions are highly visible over a wide area and there is no option to check your balance in privacy. The only consolation is that, in sleepy Diss, a mugging would be the talk of the town for months.

I had a word with the branch manager. Apparently, these machines are replacing existing units everywhere in the UK in a rolling upgrade programme. He conceded the security problems - reluctantly, after a predicatable comment that, "They must have looked into the security aspects beforehand."

I suggested that both (1) an arc-restricting filter be added, and; (2) the firmware be altered to allow an option for balances to be printed only, rather than displayed. I get the impression that the "Listening Bank" will quietly file the suggestions in the round file.

jonsg@hyphen.com Hyphen home page: http://www.hyphen.com/ jon@sundome.demon.co.uk And mine: http://www.hyphen.com/html/jonsg/

------------------------------

Date: Tue, 04 Apr 1995 10:13:10 PDT From: Nancy Leveson <leveson@cs.washington.edu> Subject: Safeware: System Safety and Computers

NEW BOOK-- Safeware: System Safety and Computers, by Nancy G. Leveson, University of Washington (leveson@cs.washington.edu), Addison-Wesley, ISBN: 01201-11972-2, $49.50.

This book examines past accidents and what is currently known about building safe electromechanical systems to see what lessons can be applied to new computer-controlled systems. One lesson is that most accidents are not the result of unknown scientific principles but rather of a failure to apply well-known, standard engineering practices. A second lesson is that accidents will not be prevented by technological fixes alone, but will require control of all aspects of the development and operation of the system. The features of a methodology for building safety-critical systems are outlined.

PART 1: The Nature of Risk (126 pages) Is there a problem? How safe is safe enough? The role of computers in accidents Software myths Why software engineering is hard Problems in ascribing causality A hierarchical model of causality Root causes of accidents Do humans cause most accidents? The need for and role of humans in automated systems

PART 2: Introduction to System Safety (50 pages) Foundations of system safety (systems theory and systems engineering) Historical development Basic concepts (hazard analysis, design for safety, management) Software system safety Cost and effectiveness of system safety Other approaches to safety (industrial engineering, reliability engineering)

PART 3: Definitions and Models (75 pages) Terminology Accident models Human task and error models

PART 4: Elements of a Safeware Program (290 pages) Managing safety (the role of management, setting policy, communication channels, setting up a system safety organization, place in the organizational structure, documentation) The system and software safety process (general tasks, real examples) Hazard analysis (what it is, how to do it, types of models, types of analysis, current models and techniques, limitations, evaluations) Software hazard analysis and requirements analysis Designing for safety Design of the human--machine interface Verification of safety (testing, software fault tree analysis)

APPENDICES: Detailed descriptions of well-researched accidents along with brief descriptions of industry-specific approaches to safety (132 pages)

A. Medical Devices: The Therac-25 story

B. Aerospace: The civil aviation approach to safety, Apollo 13, DC-10, and Challenger

C. The Chemical Industry: The chemical process industry approach to safety, Seveso, Flixborough, and Bhopal

D. Nuclear Power: How a nuclear power plant works, The nuclear power approach to safety, Windscale, Three Mile Island, and Chernobyl

------------------------------

Date: Mon, 3 Apr 1995 22:12:13 -0400 From: winn@Infowar.Com Subject: InfoWarCon '95, First Call for Papers

InfoWarCon '95 A 2 Day International Symposium on Information Warfare September 7-8, 1995 Stouffer Concourse Hotel Arlington, VA

Presented by National Computer Security Association Winn Schwartau and Interpact, Inc. Robert Steele and OSS, Inc.

For Call for Papers or further information, contact

National Computer Security Association 10 South Courthouse Avenue Carlisle, PA 17013 Phone 717-258-1816 or FAX 717-243-8642 EMAIL: 74774.1326@compuserve.com CompuServe: GO NCSAFORUM

or Winn Schwartau Interpact, Inc. Information Security & Warfare V:813.393.6600 F:813.393.6361 Email: Winn@Infowar.Com

------------------------------

Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact <risks-request@pica.army.mil> (Dennis Rears <drears@pica.army.mil>). UK subscribers please contact <Lindsay.Marshall@newcastle.ac.uk>. 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 <risks-request@csl.sri.com> (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk)

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR> cd risks<CR> or cwd risks<CR>, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J<CR>". For issues of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely.

------------------------------

End of RISKS-FORUM Digest 17.04 ************************