Text File

precedence: bulk Subject: Risks Digest 20.64

RISKS-LIST: Risks-Forum Digest Thursday 4 November 1999 Volume 20 : Issue 64

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. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.64.html> and by anonymous ftp at ftp.sri.com, cd risks .

Contents: [very busy... expect delays... P] Yet another cracked stooopid crypto scheme... (Frank Stevenson via Lenny Foner) A Risk of disk caching (Erling Kristiansen) Single-Sourcing at the FAA (Eriks A Ziemelis) Re: Aircraft computer redundancy, airline safety (Paul Wallich) Re: Y2K creates "horseless carriages" (Ted Doty) Cornell University Revisits Spring 1900 (James Byers) Bush campaign site hacked (Avi Rubin) IP blocking (Lindsay Marshall) INS Irony Explained (Paul Robinson) Fibers Cut in Massachusetts (Rich) Typing fast, and a fast computer are not necessarily good! (Vicky Larmour) Printers are too smart to handle "dumb" jobs (Leonard Erickson) Complexity in operating systems and programming languages (Diomidis Spinellis) Re: DC Metro Relays (David Lesher) BlackICE Defender Security woes (tlb) 10-day deactivation warning from Network Solutions takes 13 days (Stuart Woodward) 40 vs. 128 bit browsers (Jeremy Epstein) New Australian RISKS Archive (WestyX) Call for papers, Malicious Information Technology (Jeffrey Voas) Abridged info on RISKS (comp.risks)

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

Date: Wed, 27 Oct 1999 12:00:52 -0400 (EDT) From: Lenny Foner <foner@media.mit.edu> Subject: Yet another cracked stooopid crypto scheme...

...and yet another example of why security through obscurity, not to mention non-peer-reviewed design of cryptosystems, is just dumb. Not, I imagine, that anyone but the vendors is going to complain.

This means that DVD encryption can be cracked is something like a tenth of a second. And the next message in the thread points out that the known plaintext part is easy, too.

[Note: if you follow the URL, it appears that the message got automatically mangled by the software that threads messages into web pages; the .Z has many mailto:'s that shouldn't be there...]

- - - Begin forwarded message - - -

Date: Wed, 27 Oct 1999 14:54:17 +0200 (CEST) >From: Frank Andrew Stevenson <frank@funcom.com> To: cryptography@c2.net Subject: CSS broken

Monday sourcecode for the CSS algorithm was released through an anonymous remailer. CSS is the encryption algorithm used on DVD movies, and it was suspected that it was weak beyond just having a 40 bit key. Yesterday I found it to be vulnerable to a trivial 2^16 attack with as little as 6 bytes of known plaintext.

I posted the details on: http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/000589.html

frank

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

Date: Fri, 22 Oct 1999 20:01:52 +0200 From: Erling Kristiansen <ekristia@xs4all.nl> Subject: A Risk of disk caching

I do most of my typing in Frame Maker on a UNIX system. When I send documents, I print to a pdf file and attach it to an Email.

My company uses Lotus Notes as our standard mail platform. For most users, including myself, Notes runs on a Win95 platform. My PC mounts the disk of the UNIX system as a network drive, so I can include the pdf attachment directly from the UNIX disk into Notes.

Today, I did just that.

The recipient called me with a few modifications to the document I had just sent him.

I did the modifications, and repeated the process of generating pdf and attaching to an email. Note that, in this process, the new pdf file replaced the old one. The old file therefore no longer existed explicitly anywhere.

The recipient called me and said: You sent me the old version of the document. Can I please have the updated one.

I investigated a bit, and discovered that, consistently, once a file with a given name has been included as a Lotus Notes attachment, this version of the file will be attached to subsequent mails that call for this attachment, even if the contents of the original file has changed!

Though I have not attempted to understand the deeper logic of this, it looks like a disk caching that is unaware that somebody else may have changed a file on a networked drive, so it gives you the cached version whenever this file is called for.

In this case, no harm was done, but I can imagine quite a few "nice" scenarios resulting from obsolete files being distributed instead of current versions.

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

Date: Thu, 21 Oct 1999 08:58:17 -0600 From: Eriks A Ziemelis <eazy@ecae.stortek.com> Subject: Single-Sourcing at the FAA

From "The Chicago Tribune", 10/21/1999: http://chicagotribune.com/news/metro/chicago/article/0,2669,ART-36492,FF.html

Thomas A. Varlotta stands accused of destroying the lone copy of source code for a system to transfer flight control data between the control tower at O'Hare airport and a control center in Elgin, IL. Luckily, in a raid on Varlotta's home, authorities recovered an encrypted copy of the source code and managed to decrypt it in six months. Otherwise, 3-5 more years to rewrite the software.

Quote the FAA: "It's an efficiency issue, not a safety issue."

Paraphrasing the Department of Transportation investigator: Why did only one person have the source code? "I'm just a layman," Harper said. But "that doesn't sound like a good business practice," he said.

Comment #1: Not a safety issue? The old method of transferring data, according to the article, was via telephone. Someone mishears and/or transcribes the data incorrectly, anything in place to catch problems when a controller call out the wrong plane, a dangerous course correction/altitude change? Maybe not a safety issue, but, not comforting.

Comment #2: Noone heard of backups at the FAA? Varlotta was not working alone on the project: noone else had a copy? FAA is not backing up their software? We backup our software here every night and I still make a backup of my own every other day, just to be analy-safe.

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

Date: Sun, 17 Oct 1999 10:21:04 -0400 From: Paul Wallich <pw@panix.com> Subject: Re: Aircraft computer redundancy, airline safety (Olson, RISKS-20.63)

There are a lot of redundant items in your typical aircraft cockpit so that the plane doesn't fall out of the sky if one of them fails. If memory serves, the A320 has three flight computers, any one of which can handle the aircraft. Flying with two out of three would not then be a problem, even if you would prefer all of them functioning for maximum reliability. (And one would expect that the confused box would be swapped out or otherwise fixed overnight, without as much inconvenience to passengers.)

What would be a problem would be flying with one of your flight computers in operation but malfunctioning so that there would be arguments among them about what the plane was doing.

Paul Wallich pw@panix.com

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

Date: Thu, 21 Oct 1999 18:48:36 -0400 From: "Doty, Ted (ISSAtlanta)" <TDoty@iss.net> Subject: Re: Y2K creates "horseless carriages" (Griffith, RISKS-20.63)

>AP reports that a Y2K glitch has caused 2000 new vehicle registrations in >the state of Maine to bear the classification "horseless carriage". >Apparently, the DMV software misread the 2000 model year as 1900, and it is >hardwired to classify any vehicle with a model year before 1916 as a >horseless carriage.

This smells like an urban legend. Can you imagine a programmer at the DMV titling a category as "horseless carriage", or even a faceless bureaucrat specifying that name? It's unlikely that the DMV was computerized earlier than the 1960s, and that term just doesn't sound likely.

>http://www.mercurynews.com/breaking/docs/024281.htm"

---This link is dead, adding to the suspicion. I think someone was pulling their legs (successfully), and they got caught.

- Ted

Ted Doty, Internet Security Systems | Phone: +1 678 443-6000 6600 Peachtree Dunwoody Road, 300 Embassy Row | Fax: +1 678 443-6479 Atlanta, GA 30328 USA | Web: http://www.iss.net

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

Date: Tue, 19 Oct 1999 14:47:05 +0000 From: James Byers <jwb19@cornell.edu> Subject: Cornell University Revisits Spring 1900

On 16 Oct 1999, Cornell University seniors registering for classes via the online CoursEnroll system were greeted by the following splash screen text: "Use this service to enter your pre-enrollment requests for the Spring 1900 semester." Following this screen, the main application window proclaimed in a large font: "CoursEnroll for Spring 1900." The glitch was quickly corrected.

The relevant Cornell Y2K status page (http://www.cit.cornell.edu/y2k/services.html) states the service (Just the Facts) will be compliant sometime in October 1999. Enumerating the usual set of Y2K jitters is an exercise left to RISKS readers.

On the bright side, perhaps Cornell will finally offer those long-awaited classes in horseless carriage design come spring...

James Byers (jwb19@cornell.edu)

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

Date: Wed, 20 Oct 1999 11:56:51 GMT From: rubin@research.att.com (Avi Rubin) Subject: Bush campaign site hacked

>From the AP news wire:

The day after presidential candidate George W. Bush redesigned his campaign's Web site, hackers vandalized it by replacing his photo with a hammer and sickle and calling for "a new October revolution."

Avi Rubin

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

Date: Mon, 18 Oct 1999 13:08:04 +0100 (BST) From: Lindsay.Marshall@newcastle.ac.uk Subject: IP blocking

This was brought to the attention of readers cam-list recently:

<http://www.zdnet.com/zdnn/stories/news/0,4586,2352917,00.html>

"For a month or so earlier this year, DoubleClick Inc., an Internet advertising firm based in New York, furtively put up three different editions of its home page. Most visitors saw one version, highlighting the firm's accomplishments. Employees of a rival firm could see only another version, with a special press release touting DoubleClick's capture of one of the rival's customers. Clients being wooed saw only a third version."

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

Date: Mon, 18 Oct 1999 06:31:21 EDT From: Rfc1394a@aol.com Subject: INS Irony Explained

Someone wrote to ask me about the article I posted to Risks. Since the irony was not evident to someone it might not be evident to others so I thought I'd explain for the benefit of those who might not get it

I wrote, >> The following item was reported in the UK's Silicon.Com weekly round-up: >> >> The US government admitted this week that it had accidentally issued >> more visas for foreign high-tech workers than it had intended - 20,000 >> to be precise. Why? Because of a computer glitch. Irony once again >> rears its ugly head and slaps the authorities around the face with a wet fish.

To which a reader replied: > Apart from the irony, I wonder why this is a problem? World-wide there > are not enough high-tech workers, so getting an extra 20,000 sounds > to me like a bonus not a problem.

The irony being that too many trained technical people, such as computer programmers, were admitted than were allowed by law, yet it implies that INS apparently does not have enough trained computer programmers to keep this sort of mistake from happening!

Paul Robinson <rfc1394a@aol.com>

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

Date: Mon, 18 Oct 1999 10:30:36 -0400 From: rich@wisdom.wsc.ma.edu Subject: Fibers Cut in Massachusetts

> From our ISP:

> At about 2:30am Saturday morning (10/16) a catastrophic fiber cut occurred > on the Mass Turnpike. Literally, the classic backhoe scenario. AT&T (288 > strands), MCI Worldcomm (12 strands) and the MTA (Mass Turnpike Authority, > don't know how many strands but MITI's are among them) had their fiber > severed. This is an outage affecting people all up and down the east > coast. Don't be surprised if your bank machine won't dispense you cash > today.

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

Date: Wed, 20 Oct 1999 14:23:05 +0100 From: Vicky Larmour <vicky.larmour@camcon.co.uk> Subject: Typing fast, and a fast computer are not necessarily good!

I often wish I could type faster, and that I had a faster computer, but yesterday I wished my typing was slower and I had a slower computer!

I was inputting some text (ironically, software test details!) into an Excel 97 spreadsheet by typing the contents of one cell, pressing return, typing the contents of the next cell down, etc.

All was going well until suddenly, seeingly without warning, my Excel window simply disappeared and I was left wondering what on earth was going on. I re-started Excel and discovered I had lost an hour's rather tedious work, so I set about trying to work out why. After a little probing, it dawned on me. At the time Excel disappeared, I had been entering the text // cannot be tested in test harness in a cell.

This is what happened as I typed that text: - Evidently, Excel 97 treats a forward slash as an ALT press (highlighting the File menu button), if a cell is selected but not being edited. - the second forward slash was ignored - the space key caused the application window menu to drop down. - the "c" selected the "close" option from that menu, which brought up a dialog box saying "Do you want to save? Yes / No / Cancel". - the "a" was ignored - the "n" activated the "No" option on the dialog box. - poof! Excel closed without saving.

All this happened in the blink of an eye, as I typed, so I didn't even get to see the dialog box that might have stopped me in my tracks. It was only by careful reconstruction of exactly what I had been doing that I worked out what had happened.

The RISKS? Undocumented and inconsistent keyboard shortcuts - why should forward slash be treated as an ALT press, but not if I am already editing text in a cell? Why isn't this listed in the keyboard shortcuts in the Excel help?

[Extra RISK: My work hadn't been auto-saved because in Excel 97, you have to install the AutoSave Add-in if you want auto-save, which isn't something I had explicitly thought to do (but now have!). If Auto-save had been an item on the tools menu from the start, I might well have noticed it and switched it on!]

Vicky

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

Date: Sat, 16 Oct 1999 23:39:19 PST From: shadow@krypton.rain.com (Leonard Erickson) Subject: Printers are too smart to handle "dumb" jobs

There's been an interesting discussion going on on Fidonet's TECHNICAL echo recently. It started when an echo participant asked if anyone knew of *new* printer models that could merely be hooked up to a standard printer port and used to dump text data to.

Why was he asking? Because he'd just had the customer service departments of *every* printer company he called, said that their current model printers *will not* print except under Windows, with appropriate drivers loaded!

Since he works for the miltary, and was trying to come up with a printer his section could recommend for dumping logging data from some embedded (and very much *non* Windows) equipment, this was somewhat less than useful.

Further checking has come up with *one* printer line, and that one is expensive industrial grade equipment intended for very heavy use.

However, tests by some readers have shown that *some* "current model" printers *will* print plain text just fine. But others that are ostensibly the "same model" won't.

The risk? Windows has become so common that an important piece piece of hardware is in danger of becoming unusable *without* it. At least unless you can guarantee a *huge* market or afford custom orders.

Or, more likely, Windows has become so prominent that it's impossible to get a *non*-Windows answer from customer support.

Either way, this is going to become a real problem as more older printers go out of service.

I *was* thinking about throwing out some old Epson printers. Now I think I'll hold onto them.

Leonard Erickson (aka Shadow) shadow@krypton.rain.com

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

Date: Mon, 18 Oct 1999 12:02:11 +0300 From: Diomidis Spinellis <dds@sena.gr> Subject: Complexity in operating systems and programming languages

A number of contributors to previous digests have stressed the risks associated with increasingly bloated software applications. Unfortunately the same issues permeate a number of facets of the software industry. Consider operating systems and programming languages which are becoming increasingly complicated and their implementations less trustworthy. The following table [1] contains the number of documented system calls for some popular Un*x system versions:

Operating System Year Number of system calls First Edition Unix 1971 33 Seventh Edition Unix 1979 47 SunOS 4.1 1989 171 4.3 BSD Net 2 1991 136 HP-UX 9.05 1992 219 SunOS 5.4 1994 163 Linux 1.2 1996 211 SunOS 5.6 1997 190 Linux 2.0 1998 229

The Windows platform with 3433 API calls (up to NT4 SP3) belongs to a different league; the associated problems are documented elsewhere [2]. A system call defines an interface to the operating system; more system calls increase the complexity of the operating system needed to support them, provide additional opportunities for unwanted interactions between them, and increase the chances of overlooked security loopholes.

This increasing complexity has important implications for the reliability of software developed for a specific platform. Complicated interfaces are difficult to learn and use effectively. As a result of their size and complexity, modern operating systems exhibit an increasing number of bugs; demonstrated by the numerous "fixes" distributed by their vendors. Developers of robust applications have to take this into account coding around them, or insist on the installation of all relevant fixes. Some fixes may introduce new errors or render other system components inoperative. The bottom-line of this situation is, that the application developer is practically rarely singly responsible for the reliability of an application.

Similarly to operating systems, programming languages also have a tendency to grow in size and complexity as they mature. Taking as a rough measure the page number of the language's canonical description the following table provides an illustration of the evolution of the C and C++ programming languages:

Book Title Year Pages The C Programming Language (Kernighan and Ritchie) 1978 228 The C Programming Language; second edition 1988 272 The C++ Programming Language (Stroustrup) 1986 328 The C++ Programming Language; second edition 1991 669 The C++ Programming Language; third edition 1997 910

This trend has important implications for the developers of high-reliability systems. Large languages are difficult to learn and use [3]. It is nowadays not uncommon for programming teams to lack people who understand the whole language at a level sufficient to advise other members on issues regarding the interrelationship between language elements. Subtle bugs arising from the misunderstanding of language features can thus survive code walkthroughs. In addition, language complexity and advanced optimisation techniques combined with processor complexity results in an increased number of bugs in modern compilers. This is clearly an additional risk factor for high-reliability designs.

[1] Diomidis Spinellis. Software reliability: Modern challenges. In G. I. Schueller and P. Kafka, editors, Proceedings ESREL '99 - The Tenth European Conference on Safety and Reliability, pages 589-592, Munich-Garching, Germany, September 1999. ESRA, VDI, TUM, A. A. Balkema. http://kerkis.math.aegean.gr/~dspin/pubs/conf/1999-ESREL-SoftRel/html/chal.html [2] Diomidis Spinellis. A critique of the Windows application programming interface. Computer Standards & Interfaces, 20:1-8, November 1998. http://kerkis.math.aegean.gr/~dspin/pubs/jrnl/1997-CSI-WinApi/html/win.html [3] C. A. R. Hoare. Hints on programming language design. In Ellis Horowitz, editor, Programming Languages: A Grand Tour, pages 31-40. Computer Science Press, 1983. Reprinted from Sigact/Sigplan Symposium on Principles of Programming Languages, October 1973.

Diomidis Spinellis, University of the Aegean

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

Date: Thu, 21 Oct 1999 11:15:01 -0400 (EDT) From: David Lesher <wb8foz@nrk.com> Subject: Re: DC Metro Relays (RISKS-20.63)

> The Washington DC Metro has had rampant failures among its electronic > relays, and as a result has been running the entire system manually ...

Note these appear (from past press photos & descriptions) to be time-proven, dirt-ordinary, railroad-standard relays, such as have been used since oh, the era of Tom Thumb and/or the Golden Spike.

Everyone talking has been head-scratching; metallurgists and other specialists consulted to no avail.

We spend a lot of time in RISKS discussing new, unproven, technologies & the dangers lurking within same. But this appears to be an old old one that suddenly has fallen into the gutter for reasons unknown. I find this very disturbing.

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

Date: 17 Oct 1999 03:48:31 GMT From: "tlb" <tomeuchre@yahoo.com> Subject: BlackICE Defender Security woes

I just recently purchased the BlackICE defender program to protect my computer against internet hackers and other co-workers. While scanning the unprotected, unencrypted raw logs of the program, what do you think I found? The SMTP dialog between my mail program and my Mail server, complete with the account and password right out there in the open. Quite ironic that a company selling a product to ensure security and system integrity actually created a gaping hole. braz@mnw.net (a 2-day user of BlackICE Defender -- the product won't see 3 days on my machine).

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

Date: Sat, 30 Oct 1999 13:55:29 +0900 From: stuart@gol.com (Stuart Woodward) Subject: 10-day deactivation warning from Network Solutions takes 13 days

Due to an oversight on my behalf, payment to Network Solutions for the renewal fee for one of my domains was overlooked and in time I received a reminder that it needed to be paid. The reminder comes via an ordinary postal letter. So as soon as I got the reminder, I logged on and paid the fee at the Network Solutions website.

Since the postal letter took some time to arrive, a Deactivation Notice from Network Solutions had already been dispatched. When it arrived today it gave me a fright because the letter, giving me a final 10 days to pay, was dated 17th October 1999 and it only arrived here in Japan via Amsterdam(!) on the 30th of October.

To me this poses two questions: Why doesn't Network Solutions send an e-mail reminder to the Billing Contact when they send out the postal mail and why do they use such a slow postal delivery service for such time sensitive information?

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

Date: Mon, 18 Oct 1999 20:35:53 -0400 From: Epstein Family <jepstein@mail.mnsinc.com> Subject: 40 vs. 128 bit browsers

Wells Fargo administers the 401(k) for a previous employer, where I still have an account. Today I received a letter which reads in part:

"We have, from our initial introduction of Internet access to retirement account information nearly two years ago, recognized the value of requiring users to utilize browsers that support the strong, 128-bit encryption available in the United States and Canada. Following recent testing of an upgrade to our Internet server, we discovered that the site had been put into general use allowing access with standard 40-bit encryption. We fixed the problem as soon as it was discovered, and now, access is again only available using 128-bit encryption. ... We have carefully checked our Internet server and computer files and determined that at no time was the site accessed without proper authorization while we were using the standard encryption program. ... We have adjusted our server monitoring to test for lower encryption on an hourly basis to ensure the server is maintained at the highest encryption level for your protection."

I found this to be both reassuring (that they admitted the error) and frightening (that they state so confidently that the site was never accessed improperly, which seems a trifle strong assertion). I was also pleased to see that they're now testing for recurrences of this configuration error on a regular basis.

The letter then goes on to explain that there's no indication to IE users to indicate whether they're using 40-bit or 128-bit encryption, but Netscape 4.0 & later users can click on an icon to see the type of crypto.

While there's no explanation of how this configuration error occurred, it shows the risk of systems that *appear* secure (i.e., using 128 bit encryption), when they're really not (i.e., using 40 bit encryption). Even a reasonable effort to look at the output of the system would appear encrypted in either case; it's only if someone took a closer look at the traffic that the discrepancy would occur. Compounding this is the fact that it's not obvious (or even available) to users whether they're using a strong or weak system, and an error will go undetected a long time.

Moral of the story: if it's easy to misconfigure a system so it's insecure, that's exactly what will happen.

--Jeremy Epstein

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

Date: Mon, 18 Oct 1999 20:08:27 +1000 (EST) From: Ochran Industries <n2585464@sparrow.qut.edu.au> Subject: New Australian RISKS Archive

There is now an Australian mirror of risks at

http://mirror.aarnet.edu.au/risks/

This is a html page of the ftp files, and contains all risks issues up to risks-20.61 (02-Oct-1999).

westyX - n2585464@sparrow.qut.edu.au

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

Date: Fri, 22 Oct 1999 15:51:57 -0400 From: "Jeffrey M. Voas" <jmvoas@rstcorp.com> Subject: Call for papers, Malicious Information Technology

Co-Authored:

Software Assessment: Reliability, Safety, and Testability (Wiley, 1995) http://www.rstcorp.com/books/sa

Software Fault Injection: Inoculating Programs Against Errors (Wiley, 1998) http://www.rstcorp.com/books/sfi

Videos:

Developing Software for Safety Critical Systems (IEEE, 1998) http://www.rstcorp.com/videos/safety_critical.html

Software Testing: Building Infrastructure, Due Dilligence, and OO Software (IEEE, 1999) http://www.rstcorp.com/videos/software_testing.html

IEEE Software Call for Articles & Reviewers Malicious Information Technology: The Software vs. The People Publication: Sept./Oct. 2000

Software was intended to improve the quality of human life by doing tasks more quickly, reliably, and efficiently. But today, a "software vs. people" showdown appears eminent. Software is increasingly becoming a threat to people, organizations, and nations. For example, the spread of the Melissa virus illustrates the ease with which systems can be penetrated and the ubiquity of the consequences; the Melissa virus caused many companies to shut down their EMail systems for days or even weeks. The origin of these threats stems from a variety of problems. One problem is negligent development practices that lead to defective software. Security vulnerabilities that occur as a result of negligent development practices (e.g., commercial Web browsers allowing unauthorized individuals to access confidential data) are likely to be discovered by rogue individuals with malicious intentions. Other security vulnerabilities are deliberately programmed into software (e.g., logic bombs, Trojan Horses, and Easter eggs). Regardless of the reason why information systems are vulnerable, the end result can be disastrous and widespread.

Because of the increased danger that malicious software now poses, we seek original articles on the following specific issues:

+ Intrusion detection + Information survivability + Federal critical infrastructure protection plans + Federal laws prohibiting encryption exports vs. US corporations + State-of-the-practice in security testing + The Internet's "hacker underground" + Corporate information insurance + Penalties for those convicted of creating viruses + Case studies in information security and survivability

Submissions due: 1 April 2000

Guest Editors:

Nancy Mead Jeffrey Voas Carnie Mellon University Reliable Software Technologies nrm@sei.cmu.edu jmvoas@rstcorp.com

Authors: Submit one electronic copy in RTF interchange or MS-Word format and one PostScript or PDF version to the magazine assistant at software@computer.org. Articles must not exceed 5,400 words including tables and figures, which count for 200 words each. For detailed author guidelines, see www.computer.org/software/edguide.htm. Reviewers: Please e-mail your contact information and areas of interest to a guest editor.

Jeffrey M. Voas, Co-Founder, Reliable Software Technologies, Suite 400, 21351 Ridgetop Circle, Dulles, VA 20166 USA, jmvoas@rstcorp.com, Phone: 703.404.9293, Fax: 703.404.9295

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

Date: 23 Sep 1998 (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. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.64 ************************