Subject: RISKS DIGEST 17.49
RISKS-LIST: Risks-Forum Digest Weds 29 November 1995 Volume 17 : Issue 49
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:
Spelling Correctors Self-Applied? Not in Microsoft Word (PGN)
Another Oakland airport radar outage (PGN)
"Black Baron" gets 18-month sentence for virus activities (PGN)
Denial-of-service attack (James Burns)
New software that is just too clever (Jeffrey D. Sherman)
Alarm and alarm-silencing risks in medical equipment (John R. Strohm)
Re: Can you have enough backups? (Pete Mellor)
Re: A well-managed risk (Tom Zmudzinski)
Is chip theft high-tech crime? (Harlan Rosenthal)
Network Security Moves to Front Burner (Edupage)
CERT Summary CS-95:03 (CERT Advisory)
11th ACSAC Advanced Program (Vince L. Reed)
AMAST'96 Call for Systems Demonstrations (Pippo Scollo)
ABRIDGED info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 29 Nov 95 12:10:33 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Spelling Correctors Self-Applied? Not in Microsoft Word
A cute article by Joan E. Rigdon in the *San Francisco Sunday Examiner and
Chronicle* Computers & Technology section (``How do you spell dated? MS
Word hasn't brought dictionary into cyber-age'' -- 26 Nov 1995, B-5) points
out that the Word spellchecker makes the following suggestions for words
that putatively would seem important to Microsoft:
Internet --> interment
Internet's --> internee's
e-mail --> emboli (blood clots)
cybershoppers --> [no suggestions]
Netscape --> [no suggestions, although pretending that your
competitors don't exist is a nasty strategy.
Ms. Rigdon also notes that Microsoft should have received adequate warning
last December when the *Dallas Morning News* ran a garbled story resulting
from an editor accidentally accepting all of the alternative spellings,
including the following conversions:
Intel --> Until
Microsoft --> Microvolts
As noted in RISKS on numerous occasions, our archives are full of such
transgressions (most recently, see RISKS-17.32). [Transgreshams Law,
I suppose.] Similar to MS ignoring Netscape was Scott Siege's item in
RISKS-15.72 that the Apple MacIntosh spellchecker suggested changing
"Laserwriter" to "Laserjet" (not surprisingly, an Apple product).
------------------------------
Date: Wed, 29 Nov 95 08:01:32 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Another Oakland airport radar outage
The Oakland airport radar failed again on 28 Nov 1995 for about two hours,
beginning at 9:44am. ("The cause ... was not known.") Backup radar at
Moffett Field was used; however, it covers a smaller area, and delays were
incurred on 17 takeoffs at SFO. There had also been a brief failure on 27
Nov 1995, but it caused no disruption. Usual statements were made about how
safety was not impaired and no one should be concerned. FAA spokesman Mitch
Barker said, "We don't let it operate if it's not safe." He was also quoted
in a made-for-RISKS statement: "Things are going to go wrong from time to
time, especially with a system as complicated as this."
[Source: *San Francisco Chronicle*, 29 Nov 1995, A13. For further
background, the August 1995 Fremont (Oakland) ATC outage is discussed
beginning in RISKS-17.24 to 28. Another Fremont outage earlier this month
required the backup system to be used for two days, but was not reported in
RISKS at the time. Other ATC problems are also noted in recent RISKS -- in
Chicago (17.35) and Las Vegas (17.41). The system may be safe, but it does
not seem sound.]
[Dates have been corrected in this version, fixing an off-by-one error.]
------------------------------
Date: Wed, 29 Nov 95 08:07:51 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: "Black Baron" gets 18-month sentence for virus activities
Christopher Pile, 26, the first person in Britain to be convicted of
creating computer viruses, was jailed for 18 months. His creations
(Pathogen and Queeg) were apparently rather sophisticated stealth
viruses that used an encryption program (Smeg) to hide their presence.
------------------------------
Date: 29 Nov 95 17:49:16
From:
[email protected] (James Burns)
Subject: Denial-of-service attack
According to a front-page story by James W. Roberts in the 29 Nov 1995
_Asbury Park Press_ (NJ), a student at Monmouth University has been charged
with disrupting the school's electronic mail system for five hours by
bombarding two adminstrators with 24,000 e-mail messages. The student's
computer access had been terminated on 9 Nov 1995 because of posting
advertising and business venture solicitations to "inappropriate sections of
the Internet" (presumably, Usenet groups).
It took 44 hours to trace the source of the attack through a service
provider in Atlanta, GA and back to an account based in Red Bank, NJ, shared
by the student. The student is being charge with a federal crime because of
using interstate communication to deny service. Carl Stern of the Justice
Department is said to have remarked that this is the first time the federal
computer fraud act has been used for an act of this type.
James E. Burns, Bellcore, NVC-3X114, 331 Newman Springs Road
Red Bank, NJ 07701-5699 1-908-758-2819
[email protected]
------------------------------
Date: Wed, 22 Nov 95 03:18:03 -0500
From: Jeffrey D. Sherman <
[email protected]>
Subject: New software that is just too clever
Ray Panko's story of being outsmarted by Excel trying to be clever in
dealing with percentages reminded me of my recent struggles with WordPerfect
6.1.
I recently started using WordPerfect 6.1, upgrading from 5.2. It
has some nice features, but several strange things happened:
- I couldn't leave two spaces between a chapter number and the chapter name:
I would type two spaces but one would mysteriously disappear
- typing (c) in a list (as in (a), (b), (c)), resulted in the copyright
symbol appearing. There was no warning - in fact a document converted from
WP5.2 had to be recalled and reprinted when we noticed this change.
- I could not select part of a word with the mouse: only all of it or none
of it.
After a lot of aggravation, and buying a couple of books, I found that the
strange behaviour resulted from "enhancements" in WP6.1. I've now disabled
the enhancements, so the software will do what _I_ want.
------------------------------
Date: Wed, 22 Nov 1995 09:11:21 -0500 (EST)
From:
[email protected]
Subject: Alarm and alarm-silencing risks in medical equipment
I recently underwent total hip replacement surgery. As part of the
procedure, for pain control, the doctors fitted me with an intravenous
infusion system that gave me a continuous morphine feed in fluids at a
constant rate. The system used two intravenous infusion (IV) pumps, one to
feed the morphine into the carrier fluids (a potassium salt solution, I
think), and the other to feed the carrier fluids into me. Both pumps were
capable of operation from AC line or from internal rechargeable batteries;
this allows the patient to be transferred from the surgical suite to the
various other wards of the hospital without worrying about extension cords
on the way. The pumps have an audible alarm, and there are several
illuminated icons on the front panel to indicate the reason for the alarm.
Morphine is a controlled narcotic, and IV pumps for morphine have a number
of special features. The morphine is carried in a large syringe that is
mounted inside the pump, behind a locking panel cover. The programming
controls for the pump are behind the locking panel as well; the pump cannot
be set up or reset without the key. There is a patient-operated demand
switch, with an associated programmable lockout time, that allows the
patient to get an extra boost on demand, but no more often than the certain
interval. The patient is expected to use the switch if he anticipates a
need for more pain control than the baseline; this happens for example when
the patient is transferred between beds, or when the physical therapists
enter the room. (The physical therapists do a very necessary job that is
unfortunately not a whole lot of fun for the patient.) Additionally, the
physician will generally allow the patient to request an additional booster
dose from the nurse, at longer intervals.
Because of other medical concerns, I spent the first 24 hours or so post-op
in intensive care, rather than going immediately to the orthopedic floor.
When we transferred me up to orthopedic, the ICU nurses rearranged everything,
loaded the pumps onto a conventional IV tree, switched them over to battery
operation, and we were on our way.
Transferring a patient from an ICU bed/gurney to a standard hospital bed is
something of a production, requiring several nurses to lift and a patient
not to scream. Then all the various hoses coming out of the patient have to
be arranged, the IV pumps situated, power cords plugged in, and etc. etc.
About an hour after the transfer to orthopedic was completed, one of the
IV pumps alarmed. I called the nurse's station and told them "alarm on the
IV pump". I couldn't see the pump face to see which alarm indicator was on.
A nurse, not the one assigned to me, came in, said, "Oh, that is just the
battery alarm; you don't have to listen to that; I'll silence it." She did
something on the front panel of the morphine pump, and the alarm stopped.
I asked whether the pumps were in fact plugged in; she glanced at the
power cords and said they were.
A few minutes later, the assigned nurse came in, just as I was starting to
notice discomfort building up. She asked about the alarm; I explained; she
checked the morphine pump, and discovered that it had just shut down from
battery exhaustion. She had to go get the patient chart and the safety key
and reprogram the pump, after plugging it into the wall.
The risks in the above design should be evident. 1) There should be an
unequivocal indication, continuously present, that the pump is running on
batteries. 2) There should be no operator procedure, other than getting the
pump running on AC line power, or shutting it off completely, to silence a
low-battery alarm. 3) Personnel have to be trained to think about WHY a
particular alarm is sounding, and the implications of the alarm, BEFORE they
reach for a "Silence" key.
------------------------------
Date: Wed, 29 Nov 95 20:56:34 GMT
From: Pete Mellor <
[email protected]>
Subject: Re: Can you have enough backups? (Cushman, RISKS-17.48)
The story from <
[email protected]> about multiple failures of back-ups in
RISKS-17.48 reminded me of a somewhat similar incident which I perpetrated
many years ago while working in the Service Programming Department at ICL in
Stevenage.
The main programming effort was concentrated in the Executive Programming
Department. (The basic operating system on the ICL 1900 series was referred
to as an "executive". There was a more powerful operating system known as
GEORGE 3, but this ran on the larger machines in the range. Stevenage was
responsible for medium range machines which ran executives. I still think
that if ICL had played its cards right, GEORGE 3 could now have been a
serious rival to UNIX, but that is a separate story! :-)
Anyway, one task of Service Programming (as well as writing and maintaining
editors, assemblers and various utility programs) was to keep back-ups of
the source programs. The "executive masters", which were sources from which
a compiled executive for any hardware configuration could be derived, were
big beasts. The back-up involved running a disk-to-tape copy program, using
a grandparent-parent-child cycle of three pairs of tapes. If a pair of tapes
became full, the administrator (me) had literally to go from desk to desk
and persuade people to delete their out-of-date sources to make room for the
latest ones.
My job included reading the printed operator's log every morning to check
that the previous overnight back-up run was OK, and in particular that it
had not overflowed the two tapes. Came the day when I had neglected to do
this check for a while, and discovered that three nights previously, the
back-up had overflowed. All three generations of back-up MT had been
overwritten with a truncated copy!
Worse, the stuff that had dropped off the end included executive masters
that had not been changed for years. (They were still very live, however,
just not under active development.) The on-line medium was exchangeable disk
store (EDS). In those days, the largest EDS pack held 8 megabytes, and the
department had three drives. Only active sources were kept on-line. The
*only* copies of the masters I had lost resided on those back-up tapes.
Ouch!
I confessed. The most polite and least personal comment was from the
programming manager: "Oh my God! What are we going to do?"
*Fortunately*, on the day after the overflow, some of my colleagues had
deleted several large files. The result was that Monday night's back-up (for
the sake of illustration) had resulted in tape overflow and a truncated copy
of the back-up. On Tuesday night and Wednesday night, the actual size of the
entire back-up had been reduced, so that the second tape of the pair was
nowhere near full. (The back-up procedure was driven by a set of parameter
cards which specified which files were to be added and which deleted. The
back-up program worked by first copying any new files from disk, then
copying the child tapes to the grandparent tapes (overwriting them in the
process) omitting files which were declared as "deleted" by its parameters.)
Eureka! The "lost" data might still be there on the end of the second of one
of the pairs of tapes. So I took a program which would do a hardware
block-by-block read of a magnetic tape, patched into it a modification (in
1900 object code) so that instead of stopping at the "end of tape" (EOT)
mark, it halted with a suitable display and could then be restarted to copy
what lay beyond EOT, and so copied the tail-end of one of the less than full
back-ups.
Sure enough, there were all the files I had "lost"! My annual salary
increment began to look healthier!
For some reason, when I told my colleagues how I had saved the day, they
were less than impressed by my ingenuity, and unfortunately their responses
were couched in language which cannot be repeated in a polite forum such as
RISKS! :-)
Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB +44 (171) 477-8422
[email protected]
------------------------------
Date: Wed, 22 Nov 95 09:27:07 EST
From: "Tom Zmudzinski" <
[email protected]>
Subject: Re: A well-managed risk (Whittle, RISKS-17.47)
>> As an aircraft mechanic who once witnessed a returning aircraft
run out of fuel on the taxiway with 5,000 pounds of fuel showing
on the gauges, I tend to disagree.
This triggers an old memory: In April 1971, my then boss bought a new
Pontiac Bonneville wagon. He thought he was getting GREAT gas mileage. He
was driving all over Northern Virginia and the gauge hadn't moved since
leaving the dealership. The gauge was still registering 3/4ths of a tank
when the car ran out gas. What had happened was that the float arm had been
spot welded (accidentally? bored autoworker?) in place.
[Permission granted ... to redistribute ... electronically or otherwise
as long as the entire file is printed without substantive modification.]
------------------------------
Date: Wed, 22 Nov 95 11:33:00 -0500
From: "Rosenthal, Harlan" <
[email protected]>
Subject: Is chip theft high-tech crime?
I differ from the current practice of grouping online activity, information
theft, and component theft into "high tech" crimes. While I feel strongly
that most malintentioned online activity is covered as an instantiation of
existing law and practice, it is a different kind of activity from stealing
chips. In my mind, hijacking a truckload of RAM chips is just like
hijacking a truckload of flavorings destined for a food plant, or grabbing a
package out of the hands of someone just leaving a jewelry store: simple
theft of valuable material with low traceability. True "Internet crime"
might be using a hole in security to gather information about another
system; and that's no different in intent from using an insecurely-locked
door to breach the physical security of the building to get at the same
system.
Reductio ad absurdum: If someone breaks into my house and steals my
silverware, that's low tech crime; if they steal my computer, it's
high-tech crime; and if they take the stereo, it's medium-tech crime.
We should educate the press and public on this matter, before we find
carjacking considered a "high-tech" crime because of the engine
computers.
-Harlan Rosenthal
------------------------------
Date: Tue, 28 Nov 1995 20:09:05 -0500 (EST)
From: Educom <
[email protected]>
Subject: Network Security Moves to Front Burner (Edupage, 28 Nov 1995)
Corporate America is emerging from a lengthy state of denial, and beginning
to take measures to protect its electronic assets. Nearly half of the
respondents to an Information Week/Ernst & Young poll reported having lost
valuable information during the past two years, with at least 20 saying
they'd lost information worth more than $1 million. Nearly 70% said
security risks had worsened in the last five years, and nearly 80% now have
a full-time information security director. As one analyst noted, "As
organizational structures are flattened, corporate reliance on the
availability and integrity of information systems is becoming painfully
obvious." (*Information Week*, 27 Nov 1995, p32)
------------------------------
Date: Tue, 28 Nov 1995 10:43:44 -0500
From: CERT Advisory <
[email protected]>
Subject: CERT Summary CS-95:03
CERT Summary CS-95:03, November 28, 1995
The CERT Coordination Center periodically issues the CERT Summary to draw
attention to the types of attacks currently being reported to our incident
response staff. The summary includes pointers to sources of information for
dealing with the problems. We also list new or updated files that are
available for anonymous FTP from
ftp://info.cert.org
Past CERT Summaries are available from
ftp://info.cert.org/pub/cert_summaries
* * * * *
RECENT ACTIVITY
Since the September CERT Summary, we have seen these continuing trends in
incidents reported to us. The majority of reported incidents fit into four
categories:
1. Packet Sniffers
We continue to see daily incident reports about intruders who have installed
sniffers on compromised systems. These sniffers, used to collect account names
and passwords, are frequently installed with a kit that includes Trojan horse
binaries. The Trojan horse binaries hide the sniffer activity on the systems
on which they are installed.
For further information and methods for detecting packet sniffers and Trojan
horses, see the following files:
ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
ftp://info.cert.org/pub/cert_advisories/CA-94:01.README
ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksum
ftp://info.cert.org/pub/cert_advisories/CA-94:05.README
2. Exploitation of SGI lp Vulnerability
The vulnerability described in CERT advisory, CA:95:15 "SGI lp Vulnerability"
continues to be exploited, though we have seen a decline in the number of
reports since the advisory was released on November 8. Intruders gain
unauthorized access to Silicon Graphics, Inc. (SGI) IRIX systems through a
passwordless lp account; they use this initial access to leverage additional
privileges on the compromised system.
As distributed by SGI, the lp account (as well as other accounts), has no
password on a newly installed system. This fact is addressed in the
documentation that SGI distributes with their systems: "IRIX Advanced Site
and Server Administrative Guide" (see the chapter on System Security).
More information on this vulnerability and how it can be addressed can be
obtained from
ftp://info.cert.org/pub/cert_advisories/CA-95:15.SGI.lp.vul
3. Network Scanning
We continue to receive several reports each week of intruders using the
Internet Security Scanner (ISS) to scan both individual hosts and large IP
address ranges. The ISS tool, which is described in CERT advisory CA-93:14
"Internet Security Scanner", interrogates all computers within a specified
IP address range, determining the security posture of each with respect to
several common system vulnerabilities. Intruders use the information
gathered from such scans to gain unauthorized access to the scanned sites.
As part of a defensive strategy, you may want to consider running ISS against
your own site (in accordance with your organization's policies and procedures)
to identify any possible system weaknesses or vulnerabilities, taking steps to
implement security fixes that may be necessary. ISS is available from
ftp://info.cert.org/pub/tools/iss/iss13.tar
More information about the ISS tool and steps for protecting your site are
outlined in the following documents:
ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner
ftp://info.cert.org/pub/cert_advisories/CA-93:14.README
ftp://info.cert.org/pub/tech_tips/security_info
ftp://info.cert.org/pub/tech_tips/packet_filtering
4. Sendmail Attacks
New reports of intruders attacking sites through sendmail vulnerabilities are
continuing to arrive daily, although most reports indicate the attacks have
failed. The types of attacks are varied, but most are aimed at gaining
privileged access to the victim machine.
We encourage sites to combat these threats by taking the appropriate steps,
described in the following documents:
ftp://info.cert.org/pub/cert_advisories/CA-95:05.sendmail.vulnerabilities
ftp://info.cert.org/pub/cert_advisories/CA-95:05.README
ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability
ftp://info.cert.org/pub/cert_advisories/CA-95:08.README
ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul
ftp://info.cert.org/pub/cert_advisories/CA-95:11.README
* * * * *
WHAT'S NEW in the CERT FTP Archive
We have made the following changes since the last CERT Summary (September 26,
1995).
* New Additions
ftp://info.cert.org/pub/cert_advisories/
CA-95:12.sun.loadmodule.vul
CA-95:13.syslog.vul
CA-95:14.Telnetd_Environment_Vulnerability
CA-95:15.SGI.lp.vul
ftp://info.cert.org/pub/cert_bulletins/
VB-95:07.abell (lsof)
VB-95-08.X_Authentication_Vul
ftp://info.cert.org/pub/tools/sendmail
sendmail/sendmail.8.7.1.tar
sendmail/sendmail.8.7.1.tar.Z
* Updated Files
ftp://info.cert.org/pub/cert_advisories/
CA-93:16a.README (sendmail - note to use smrsh with all versions)
CA-95:05.README (sendmail - date of Digital Equipment's patch)
CA-95:08.README (sendmail - note to use smrsh with all versions)
CA-95:10.README (ghostscript - patches and explanations)
CA-95:13.README (syslog - information from vendors)
CA-95:14.README (telnetd - information from vendors; correction to
compilation example)
ftp://info.cert.org/pub/tools/cops
README (more recent email address for COPS author Dan Farmer)
* * * * *
HOW TO Contact the CERT Coordination Center
Email
[email protected]
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST
(GMT-5)/EDT(GMT-4), and are on call for
emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
To be added to our mailing list for CERT advisories
and bulletins, send your email address to
[email protected]
CERT advisories and bulletins are posted on the USENET news group
comp.security.announce
If you wish to send sensitive incident or vulnerability information to CERT
staff by electronic mail, we strongly advise that the email be encrypted.
We can support a shared DES key, PGP, or PEM (contact CERT staff for details).
Location of CERT PGP key
ftp://info.cert.org/pub/CERT.PGP_key
* * * * *
Copyright 1995 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and credit is given to the CERT
Coordination Center.
CERT is a service mark of Carnegie Mellon University.
------------------------------
Date: Wed, 15 Nov 1995 22:39:27 -0600
From:
[email protected] (Vince L. Reed)
Subject: 11th ACSAC Advanced Program
The conference committee for the 11th Annual Computer Security Applications
Conference (ACSAC) is proud to announce the conference home page. It is
available on the world wide web at:
http://www.isse.gmu.edu/~csis/acsac/acsac95.html
Vince Reed, CISSP
11th ACSAC Publicity Cochair
1500 Perimeter Pkwy., Suite 310, Huntsville, AL 35806
Phone-205.890.3323, FAX-205.830.2608
[The next conference is 11-15 Dec 1995. Joe Bob says check it out. PGN]
------------------------------
Date: Wed, 29 Nov 1995 00:54:42 +0100
From:
[email protected] (Pippo Scollo)
Subject: AMAST'96 Call for Systems Demonstrations
[A Postscript version of the full announcement is available on the AMAST'96
WWW page, at URL:
http://www.pst.informatik.uni-muenchen.de/amast96/
-- this version is starkly reduced by PGN.]
[To subscribe to the AMAST'96 mailing list:
[email protected]]
AMAST '96, July 1-5, 1996
Fifth International Conference on
Algebraic Methodology and Software Technology
Ludwig-Maximilians-Universitaet, Munich, Germany
Call for Systems Demonstrations
The major goal of the AMAST Conferences is to put software development
technology on a firm, mathematical foundation. Particular emphasis is given
to algebraic and logical foundations of software technology. An eventual
goal is to establish algebraic and logical methodology as a practically
viable and attractive alternative to the prevailing ad-hoc approaches to
software engineering. We invite submissions of system demonstrations
showing the improved effectiveness of software developed on a mathematical
basis.
The topics of interest include, but not limited to, the following:
SOFTWARE DEVELOPMENT ENVIRONMENTS
SUPPORT FOR CORRECT SOFTWARE DEVELOPMENT
SYSTEM SUPPORT FOR REUSE
TOOLS FOR PROTOTYPING, VALIDATION AND VERIFICATION
THEOREM PROVING SYSTEMS
We invite prospective authors to submit 6 copies of system demo proposals (4
double spaced pages maximum) in an area relevant to the conference theme.
Papers should provide adequate information for the reviewers to assess the
significance and anticipated impact of the system on software technology.
All submissions must be sent to the program chair at the address below; the
proposals must be received by January 15, 1996 (new extended deadline).
Martin Wirsing, AMAST'96 Program Chair
Institut fur Informatik, Universitaet Munchen
Leopoldstr. 11B
D-80802 Munchen, Germany
Phone: ++49/89/ 2180-6317 Fax: ++49/89/ 2180-6310
e-mail:
[email protected]
General Chair: Maurice Nivat (France)
Program Chair: Martin Wirsing (Germany)
[Excellent program committee omitted for space reasons. PGN]
Invited Speakers include
Manfred Broy (Programming Methodology),
Jose Fiadeiro (Algebraic and Logical Foundations),
Rick Hehner (Programming Methodology),
Doug Smith (Software Development).
Proceedings will be published by Springer-Verlag.
For bulletins on current status of the conference:
http://www.pst.informatik.uni-muenchen.de/konferenzen
[email protected]
Tools and Demos:
[email protected]
Registration:
[email protected]
Local Arrangements:
[email protected]
------------------------------
Date: 6 September 1995 (LAST-MODIFIED)
From:
[email protected]
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 <
[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]
CONTRIBUTIONS: to
[email protected], 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 unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, 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.49
************************
