Text File

precedence: bulk Subject: Risks Digest 21.18

RISKS-LIST: Risks-Forum Digest Thursday 4 January 2001 Volume 21 : Issue 18

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/21.18.html> and by anonymous ftp at ftp.sri.com, cd risks .

Contents: Revenge of Y2K, Norwegian trains halted 31 Dec 2000 (Jan L) 7-Eleven unable to process credit cards since 1 Jan 2001 (Steve Hutto) Y2K+1 bug in Sharp Organizer? (Philip Berman) Power cut hits hundreds of millions in India (Edelson Doneel) Repeated computer outages for Swedish bank (Ulf Lindqvist) Telephone outage caused by water-main break (Glenn C. Lasher Jr.) Computer blamed for Russian rocket crash (Peter Neumann) Chinook: key facts ignored by those who want to clear pilots (John O'Connor) CIOs: "What, Me Worry?" (NewsScan) Automatic firmware upgrades in home electronics (Andrew Klossner) Hackers hack science exam (Winn Schwartau) Re: Seattle Hospital Hacked (Daniel Theunissen) Re: IBM and Intel push copy protection ... (Patrick P Gelsinger) Re: IMPORTANT MESSAGE FROM EGGHEAD.COM CEO (Gary Lawrence Murphy) Re: The risk of a seldom-used URL syntax (Crispin Cowan) The top 10 privacy stories of 2000 (Richard M. Smith) Stefan Brands: PKI, digital certificates, and privacy (PGN) Submission Deadline for USENIX Security Symposium, 1 Feb 2001 (Monica Ortiz) Call For Papers - RAID'2001 (Giovanni Vigna) Abridged info on RISKS (comp.risks)

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

Date: Mon, 01 Jan 2001 17:12:21 +0100 From: janl@linpro.no Subject: Revenge of Y2K, Norwegian trains halted 31 Dec 2000

Original story in "Dagbladet ... nettet" in Oslo (In Norwegian: http://www.dagbladet.no/nyheter/2000/12/31/235007.html)

Abstracted:

In the morning of 31 Dec 2000, departures of the Airport Express train and six "Signatur" departures were hit by a date handling problem. The airport trains were quickly back in action, the 07:28 Signatur departure from Kristiansand was canceled, and the five other departures were serviced by older trains.

Preben Colstrup, a spokesperson for NSB, verifies that the trains appears to not handle the date 31 Dec 2000 at all, he has no idea why. He promises that all trains will be on schedule on 01 Jan 2001. NSB adds that the trains still have not passed acceptance and belongs to the contractor, Adtranz.

Ronny Solberg in Adtranz says that the problem was solved by setting the date on the trains back a month. It only takes a few minutes, but it took time to get service people around to all the trains. He stresses that all trains were Y2K tested, but that no-one thought of testing 31 Dec 2000. He promises that the problem will be found and fixed permanently.

Dictionary:

- NSB: Norges StatsBaner, the publicly owned train company in Norway - Signatur and Airport trains: New high speed trains made for NSB by Adtranz. Presumably carrying the same computer systems. Signatur is used for long inter city routes.

Addendum: Later in the day, on national radio news a technical person in NSB speculated that the problem might have been that Y2K was a leap year and the number of days at the end of the year baffled the computers which *did* handle 29 Feb 2000 well. There were no reports of non-starters on 01 Jan 2001.

[Quite a few readers noted an AP story in various US sources, including http://www.nytimes.com/aponline/technology/AP-Norway-Y2K-Bug.html which roughly mirrors the dagbladet item. PGN]

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

Date: Wed, 3 Jan 2001 13:43:51 -0700 (MST) From: Steve Hutto <shutto@kata.chezns.org> Subject: 7-Eleven unable to process credit cards since 1 Jan 2001

The Denver Post reported today (http://www.denverpost.com/business/biz0103e.htm) that 7-Eleven stores have not been able to process credit-card transactions since January 1, 2001. The problem appears to be a faulty date-window fix for Y2K, reading the two digit current year of "01" as "1901". A programmatic check in the system rejects credit cards with expiration dates 100+ years in the future. One wonders if they rushed to implement their new information system in order to be Y2K compliant, deciding to skip low-priority system testing to make the deadline. Relevant excerpt from the end of the article:

7-Eleven's retail information system, which handles almost all of the store's operations, from payroll to purchases, was implemented into all of its U.S. stores by late 1999. It was deemed Y2K-compliant. The home of the Big Gulp didn't spend any money to ensure its systems would roll over correctly from 2000 to 2001. [...]

[Also http://www.washingtonpost.com/wp-dyn/articles/A16320-2001Jan3.html] [More likely a special-case fix that worked *only* in 2000, to avoid Y2K, as suggested by Jeremy Epstein. PGN]

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

Date: Wed, 3 Jan 2001 11:30:08 -0500 From: "Berman, Philip" <Philip.Berman@itt.com> Subject: Y2K+1 bug in Sharp Organizer?

I turned my Sharp YO-550 Electronic Organizer on today for the fist time since last year. It displayed an error message that all data was corrupted and will be erased. About 4 years of notes and phone numbers lost (yes you can back it up to a computer - The backup kit cost about the same as the organizer). After my initial reaction I turned the unit off and on and it came up seemingly working correctly although it thought it was 1997. I reloaded the current time and date. Upon turning the unit off and on the same error condition resulted (Lost all data including current time and date). Several times I set the date to 2001 with the same error resulting. I then (for some strange reason) tried setting the date to 1/1/2000. The unit worked correctly. In fact with several dates prior to 2001 the error condition never occurred. If I set the date to 2001 or greater it goes into error and loses all memory.

I write to RISKS to find out if other owners of Sharp Organizers have experienced this problem. I have been unable to reach anyone at Sharp (Customer Service Phone is always busy) to comment on the problem.

Philip Berman <philip.berman@itt.com>

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

Date: Tue, 2 Jan 2001 12:06:09 -0500 From: "Edelson, Doneel" <doneel.edelson@eulergroup.com> Subject: Power cut hits hundreds of millions in India

On 2 Jan 2001, the electrical grid for the entire northern region of India collapsed, affecting 226 million people. The outage began at a substation in Uttar Pradesh, and spread to neighboring states (Punjab, Kashmir, Rajasthan, Haryana and Himachal Pradesh) and to the capital, New Delhi. Trains, signalling systems, and the New Delhi airport were affected. Demand is often greater than supply, but such widespread outages are apparently unusual. [PGN-ed; see also http://www.cnn.com/2001/ASIANOW/south/01/02/india.blackout/index.html]

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

Date: Thu, 4 Jan 2001 15:46:33 -0800 (PST) From: Ulf Lindqvist <ulf@csl.sri.com> Subject: Repeated computer outages for Swedish bank

As reported in various Swedish news media, The Swedish bank Nordbanken has suffered repeated computer outages during late December and early January. The outages, each with a duration of several hours, shut down ATMs, Internet bank services, debit card purchases and office teller services for Nordbanken's 3.5 million customers.

In an article on the Swedish CNN Web site (cnn.passagen.se) 4 Jan 2001, Nordbanken CEO Magnus Falk says that the bank still does not know what caused the outages, but that they are now able to restart their system faster the next time it crashes...

Ulf Lindqvist, System Design Lab, SRI International, 333 Ravenswood Ave, Menlo Park CA 94025-3493, USA +1 650 859-2351 http://www.sdl.sri.com/

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

Date: Thu, 28 Dec 2000 16:29:08 -0500 (EST) From: "Glenn C. Lasher Jr." <glasher@nycap.rr.com> Subject: Telephone outage caused by water-main break

On Thursday, 28 November 2000, 17 of the 21 telephone exchanges in the City of Schenectady NY were taken out of service by a water-main break (for those not familiar with the North American phone system, exchanges uniformly contain a range of 10,000 phone numbers). The Central Office serving downtown Schenectady is located on the block between Franklin and State Streets and Jay and Clinton Streets. The water main break was on Clinton St, and caused the closure of Clinton and State Streets. The break occurred at 3 AM, and the phones went out around 9 AM.

The cellular telephone networks appear to be unable to cope with the additional traffic. I received a frantic call from my wife, who called me at work from her cell phone to tell me the house phone was out. The signal quality was extraordinarily bad, as is the nature of CDMA digital when the cell is overloaded. One is left to assume that users of FDMA and TDMA-based phones may have been cut off completely, especially analog phone users, where the cells have a hard limit of 20 simultaneous calls.

Meanwhile, my Internet service, provided by TV cable, continues unabated.

So, where do we begin on this one? Well, here are the RISKS:

1. Placement of mission-critical equipment below ground level leaves it susceptible to flooding. One might assume that an unusually heavy downpour might also have caused problems here.

2. This is a good example of network stress, looking at the behaviour of the cellular networks.

3. This is also a classic demonstration of a single point of failure. A problem in one location has cut off a critical service to an entire (although small) city. It does not matter if your service is through the IBOC (Verizon, in this area) or a CLEC (Sprint, AT&T, Met Tel, to name a few), all fo the equipment is owned and maintained by the IBOC and housed at the corner of Franklin and Clinton.

4. It is also a classic demonstration of diverse paths, as my Internet service continues to run. It does not pass through that same building, but is rather located a mile away on Eastern Parkway (or at least I believe that is the location).

glasher@nycap.rr.com

[As an addendum on 29 Dec 2000, the majority of the phone service in the city was restored as of this morning, 29 Dec. During the outage, the city was being patrolled by police, DPW trucks, Amateur (HAM) radio operators, GMRS radio operators, and telco vehicles. A command post was set up at the city police station to serve as a center of all of these diverse communications.

It is further worth noting that the telco vehicles were equipped only with cellular phones for communications. As mentioned before, the cellular networks were next to useless due to traffic overload. For this reason, the ad-hoc radio network that was established became the primary means of emergency communication. This information was gathered by listening on two of the frequencies used: 147.06 MHz (the local HAM repeater) and 462.550 (the GMRS channel that was in local use). Other frequencies could have been monitored as well, but since my monitoring was being sent back out through an MP3 broadcaster, the content needed to be constrained. GCL]

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

Date: Mon, 1 Jan 2001 11:01:13 -0800 (PST) From: Peter Neumann <Neumann@CSL.sri.com> Subject: Computer blamed for Russian rocket crash

The Ukrainian space rocket design bureau blamed "computer faults" for the failure of a Ukrainian Tsiklon-3 light booster rocket that carried 6 small satellites for the Russian Defense Ministry and space agency Rosaviakosmos. The rocket engines were shut down 367 seconds after lift-off (presumably automatically). [Source: CNN, 1 Jan 2001 (a.k.a. as 1/1/01!!!!); PGN-ed; http://www.cnn.com/2001/TECH/space/01/01/space.russia.crash.reut/index.html]

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

Date: Wed, 03 Jan 2001 18:12:17 From: "John O'Connor" <jpoc@hotmail.com> Subject: Chinook: key facts ignored by those who want to clear pilots

The risk of allowing techno mumbo jumbo to get in the way of the truth:

Whenever I read about the Chinook crash on the Mull of Kintyre, I observe that a number of important facts are conveniently ignored. These particular facts are not in dispute and they give incontrovertible proof that the pilots were acting negligently.

Instead, the spectre of some mysterious fault is raised as an argument that the pilots should be absolved of blame.

A few minutes before the accident, the helicopter was traveling at low level across the open sea. It was flying under Visual Flight Rules. VFR involves looking out of the window to see where you are going, which way up you are and to make sure that you do not hit anything. To operate under VFR, requires good visibility. (The actual requirements in terms of how many miles you must be able to see and how far you must be from cloud varies with aircraft type, pilot qualifications and where you are flying.)

The Mull itself was covered in fog and low cloud and, as the flight neared the Mull, it entered this area of reduced visibility. Now, at this point, the crew were in full command of their aircraft and had no technical problems. There has been no dispute over this.

As soon as they encountered the cloud, the crew must have switched to Instrument Flight Rules. That means referring to instruments to see which way is up and to find out where you are and it also means operating at or above the Minimum Safety Altitude. The MSA is defined as being one thousand five hundred feet above the highest obstacle on your flight path or within ten miles either side.

The purpose of these figures is, in part, to give a margin for error but also to give pilots enough room to get out of trouble. For example, an aircraft flying inside cloud might suddenly find that it is picking up ice sufficient to mean that it cannot maintain altitude. By operating at the MSA, the pilot will have enough room to either side to turn back and fly out of the icing zone and shed the ice before being forced to the ground.

Now, when the pilots of the accident aircraft encountered the cloud and fog around the Mull, they were not only below the MSA, they were actually below the high ground which they were approaching. Given this, the crew were required to make a 180 degree turn and fly out of the cloud. That is what they were trained to do. That is what the law required them to do and that is what the RAF rules required them to do.

Instead, they opted to fly on towards the high ground and attempt to climb over it. Doing so was inarguably an act of negligence or recklessness that endangered the aircraft.

The case that is made, that the aircraft may have suffered from some form of systems glitch that made it incapable of out climbing the rising ground, has no bearing on this. If the pilots had not made the decision to fly, in cloud, towards high ground at an altitude lower than the tops of the hills, the accident would not have happened. The decision that they made went against both their training and the law.

Suppose that I decided to try to drive through the centre of my town as fast as I could and that I found that my brakes failed and I crashed and caused many deaths. Can I say that it was not my fault and that the accident would have not happened if my brakes had not failed? Of course not. Whether or not there is a problem with the Chinook is an important matter but it does not absolve the crew of the helicopter from blame for entering cloud at such a low altitude. Had they not decided to do that, the accident would not have happened.

John O'Connor: http://www.jpoc.net

[In some cases, but not this case, one could ask for a Mull-again (mulligan, or do-over, in golf parlance). PGN]

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

Date: Thu, 04 Jan 2001 11:53:18 -0700 From: "NewsScan" <newsscan@newsscan.com> Subject: CIOs: "What, Me Worry?"

A national poll of 1,400 CIOs reveals that 90% have confidence in their network security, despite estimates that billions of dollars are lost every year to cybercrime. The survey, conducted by RHI Consulting, has raised eyebrows among security experts who point out that it's generally in a CIO's best interest to keep quiet when security breaches occur. A recent survey conducted by the Computer Security Institute indicated that more than half of the respondents said they did not report the intrusions to law enforcement out of fear of negative publicity or that rival companies would use the information to competitive advantage. In addition, many CIOs may feel that they must live with a "buffer of acceptable risk." "Just as credit card companies accept some level of loss as a cost of doing business, so some CIOs are saying, 'if I do a really solid job of protecting my systems, then I can live with the low-level pain that some break-ins cause,'" says one expert. Meanwhile, a 1999 survey found that Fortune 1000 companies lost more than $45 billion in thefts of proprietary information that year. [*InfoWorld*, 3 Jan 2001; NewsScan Daily, 4 Jan 2001]

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

Date: Wed, 27 Dec 2000 09:42:45 -0800 From: Andrew Klossner <andrew@cesa.opbu.xerox.com> Subject: Automatic firmware upgrades in home electronics

Consumer DVD (video) players are also adopting this "load firmware from a data source" approach. My Phillips-Magnavox DVD850 will slurp up a new firmware load from a DVD. Video DVDs include a good deal of active content, and the industry seems to expand the programming environment on a regular basis. The DVD of the popular movie "The Matrix" wouldn't work at all on half of the installed players when it shipped in 1999 because it used up-to-the-minute constructs.

When the authoritarian software forbids me to skip past a twenty-second copyright notice, it makes me nostalgic for the old 12-inch laser disks.

Andrew Klossner (andrew@cesa.opbu.xerox.com)

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

Date: Thu, 21 Dec 2000 10:36:20 -0500 From: Winn Schwartau <winns@gte.net> Subject: Hackers hack science exam

Two 8th-grade honor students in Tampa, Hillsborough County, Florida, hacked into the school computer and copied the final exam for one of their courses. They have been suspended. [PGN-ed]

We've wired up the country's schools, put the kids on the Internet, and only a small handful of teachers have any clue as to what goes on behind the mouse button. The teachers are not technically trained, they are underpaid and underappreciated. Is it any wonder? And I doubt the kids have been taught the first thing about CyberEthics by their schools or their parents.

Winn Schwartau

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

Date: Thu, 28 Dec 2000 19:05:17 -0500 From: "Daniel Theunissen" <dtheunis@earthlink.net> Subject: Re: Seattle Hospital Hacked (RISKS-21.14)

The first response to intrusion news stories by most organizations is almost formulaic: deny the attack, make (often false) allegations that this could never happen HERE, attack the credibility of the source of the news, and lastly take a stand against such heinous activity. The response by the UWMC to the intrusion into their network generally follows the formula.

They started back-pedaling the next day: "We have received the first tangible evidence from news-gathering organizations that someone did, in fact, gain criminal access to a limited number of administrative databases that contain some confidential information on at least 5,000 cardiology and rehabilitation medicine patients treated at our hospital," said Tom Martin, director and chief information officer for University of Washington Medical Centers Information Systems. >From MSNBC: "Hospital Confirms Hacking Incident" 2000-12-8

For more complete coverage, I recommend going to where the story broke: www.SecurityFocus.com and search on "University of Washington Medical Center"

The original UWMC announcement, however, is still true. Read it carefully, they worded it so that they never actually denied the attack.

Dan Theunissen, dan.theunissen.no.spam@ieee.org

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

Date: Tue, 26 Dec 2000 06:35:10 -0500 From: "Gelsinger, Patrick P" <patrick.p.gelsinger@intel.com> Subject: Re: IBM and Intel push copy protection ... (Gilmore, RISKS-21.17)

[Received via Dave Farber, whom Patrick had requested to post a correction.]

Content protection technology misinformation generates negative web-press coverage:

An article on *The Register* website "Stealth plan puts copy protection into every hard drive" contains false information that the 4C's (Intel, IBM, MEI, Toshiba) Content Protection for Recordable Media (CPRM) is to be applied to all PC hard drives. It is misinterpreting a specification for use of CPRM with the Compact Flash media format (which supports either semiconductor flash memory or IBM microdrives) probably because Compact Flash uses the same command protocol interface as standard PC harddrives. The technology is neither intended nor licensed for use with PC harddrives and is optional even for the supported media types (flash memory and microdrives). John Gilmore, a noted privacy and consumer advocate, has picked up the article and further propagated the erroneous information and mentioned Intel "IBM&Intel push copy protection into ordinary disk drives". I have alerted public relations at Intel and are disseminating accurate information within Intel and among our industry contacts.

Pat

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

Date: 29 Dec 2000 10:23:55 -0500 From: Gary Lawrence Murphy <garym@canada.com> Subject: Re: IMPORTANT MESSAGE FROM EGGHEAD.COM CEO (RISKS-21.16)

There is another implicit risk in these stories which I am always quick to bring to the attention of my would-be B2C e-commerce clients.

Suppose you have 500,000 VISA/MC numbers in your computer, and suppose you have strong cryptographic SSL connections and all that certificate jazz to ensure the customer and the e-store are who they say they are. Let's also say that I am an organized crime boss who knows you have those charge card numbers and have the means and desire to rack up just $20 worth of purchase from each of them for a cool fast million dollar profit ... now (and here's the kicker) what is to stop me from offering your system administrator some tidy sum (even 10%!) to just slip in a floppy disk and grab me a copy of the data?

Related to this, I asked a leading e-commerce Web site architect if the DLL that contained the personal information access username and password might be used by _any_ program that ran on the server (in java, a class can be made accessible _only_ to a restricted set of applications). The answer was that they hadn't thought of that.

Gary Lawrence Murphy <garym@teledyn.com> TeleDynamics Communications Inc Business Innovations Through Open Source Systems: http://www.teledyn.com

[Simson Garfinkel commented: I simply do not understand why companies insist on keeping the old VISA/MC numbers in their computers.]

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

Date: Wed, 27 Dec 2000 12:02:24 -0800 From: Crispin Cowan <crispin@wirex.com> Subject: Re: The risk of a seldom-used URL syntax (Warnock, RISKS-21.16)

This is not new. Spammers have been using these tactics (both @ in the domain name, and decimal and octal IP numbers in place of DNS names) to obscure the actual site hosting their spam content for at least a year. It's annoying, because it takes extra effort to parse out the true host of the web site being spammed. Conversely, its convenient, because it provides incontrovertable evidence that the post in question is a spam, because there is no valid reason to obscure an URL in this way other than to hide the guilty.

Crispin Cowan, Ph.D., Chief Research Scientist, WireX Communications, Inc. http://wirex.com Free Hardened Linux Distribution: http://immunix.org

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

Date: Thu, 28 Dec 2000 18:24:42 -0500 From: "Richard M. Smith" <rms@privacyfoundation.org> Subject: The top 10 privacy stories of 2000

It's the end of the year and time for everyone's top 10 list. The Privacy Foundation just released today its top ten list of privacy stories for the year 2000.

Our press release is online at: http://www.privacyfoundation.org/release/top10.html

Richard

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

Date: Fri, 15 Dec 2000 08:16:00 -0800 From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Stefan Brands: PKI, digital certificates, and privacy

Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy Stefan A. Brands ISBN 0-262-02491-8 For more information, please visit http://mitpress.mit.edu/promotions/books/BRAUHF00 [from which this is taken. PGN]

As paper-based communication and transaction mechanisms are replaced by automated ones, traditional forms of security such as photographs and handwritten signatures are becoming outdated. Most security experts believe that digital certificates offer the best technology for safeguarding electronic communications. They are already widely used for authenticating and encrypting e-mail and software, and eventually will be built into any device or piece of software that must be able to communicate securely. There is a serious problem, however, with this unavoidable trend: unless drastic measures are taken, everyone will be forced to communicate via what will be the most pervasive electronic surveillance tool ever built. There will also be abundant opportunity for misuse of digital certificates by hackers, unscrupulous employees, government agencies, financial institutions, insurance companies, and so on.

In this book Stefan Brands proposes cryptographic building blocks for the design of digital certificates that preserve privacy without sacrificing security. Such certificates function in much the same way as cinema tickets or subway tokens: anyone can establish their validity and the data they specify, but no more than that. Furthermore, different actions by the same person cannot be linked. Certificate holders have control over what information is disclosed, and to whom. Subsets of the proposed cryptographic building blocks can be used in combination, allowing a cookbook approach to the design of public key infrastructures. Potential applications include electronic cash, electronic postage, digital rights management, pseudonyms for online chat rooms, health care information storage, electronic voting, and even electronic gambling.

Stefan A. Brands is Distinguished Scientist at Zero-Knowledge Systems, Inc., Montreal, Canada.

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

Date: Thu, 04 Jan 2001 13:31:07 -0800 From: Monica Ortiz <monica@usenix.org> Subject: Submission Deadline for USENIX Security Symposium, 1 Feb 2001

10th USENIX Security Symposium 2001 Conference 13-17 August 2001, Washington, D.C., USA Conference URL: http://www.usenix.org/events/sec2001 Sponsored by USENIX, the Advanced Computing Systems Association Paper submissions due: 1 February 2001 Program Chair Dan S. Wallach, Rice University Invited Talks Coordinator Greg Rose, Qualcomm

For more details on the submission process, authors are encouraged to consult the detailed author guidelines on the symposium website at: http://www.usenix.org/events/sec01/cfp/guidelines.html

USENIX Security Symposium 2000 is sponsored by USENIX, the Advanced Computing Systems Association, USENIX is an international membership society.

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

Date: Tue, 02 Jan 2001 07:03:57 -0800 From: Giovanni Vigna <vigna@cs.ucsb.edu> Subject: Call For Papers - RAID'2001

Fourth International Symposium on Recent Advances in Intrusion Detection 10-12 October 2001, University of California, Davis, CA, USA

[Abridged for RISKS. See http://www.raid-symposium.org/Raid2001 for complete notice -- and by 31 Jul 2001, the preliminary program. PGN]

RAID executive committee chair: Marc Dacier (IBM Research, Switzerland) Program co-chair: Wenke Lee (NC State University, USA) Program co-chair: Ludovic Me (Supelec, France)

Full and short papers submitted [by 30 Mar 2001] to RAID must be original contributions, not published or submitted to other conferences. Full papers are limited to 6000 words, short papers to 2000, full page figures being counted as 300 words. [...]

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

Date: 26 Dec 2000 (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 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. http://the.wiretapped.net/security/info/textfiles/risks-digest/ . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing

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

End of RISKS-FORUM Digest 21.18 ************************