Text File

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

RISKS-LIST: RISKS-FORUM Digest Tuesday 7 December 1993 Volume 15 : Issue 32

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: FAX sends instead of receives (John McKay) Risks of conference calls "lack of announcement" Apple Computer Distributes a CD-ROM with a "Trojan Horse" (Saul Tannenbaum) French Wiretaps (Mich Kabay) Tokyo bank fraud (Mich Kabay) German Radicals use Computers (Mich Kabay) NJ credit thefts (Mich Kabay) Counterfeits (Mich Kabay) AIDS data stolen in Florida (Mich Kabay) Unauthorized changes of address (George Zmijewski) Massive credit card fraud (Mich Kabay) Lufthansa Warsaw crash - A Clarification (Peter B Ladkin) Reminder for DCCA-4: Fourth IFIP Working Conference (Flaviu Cristian)

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line; others may be ignored! Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially .UUCP folks. If you cannot read RISKS locally as a newsgroup (e.g., comp.risks), or you need help, send requests to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS".

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>YourName<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.10.1]. ************ AFTER 10 DEC 1993, CRVAX.SRI.COM = [128.18.30.65] ************ <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories.

IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM .

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.

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

Date: Tue, 7 Dec 1993 16:56:43 -0500 From: mckay@alcor.concordia.ca (John McKay) Subject: FAX sends instead of receives

Today I tried to send a FAX to a local lawyer. It dialed but instead of reading the paper it generated a copy of a document from the lawyer to a Canadian Embassy many thousands of miles away. Moral: Don't use FAX if you want it to get there!

[A fine example of a nonatomic transaction at the lawyer's end. PGN]

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

Date: Tue, 7 Dec 93 10:55:38 -0600 From: remail@tamsun.tamu.edu Subject: Risks of conference calls "lack of announcement"

Comments: This message DID NOT originate from the address listed in the From line. It was remailed by an automated remailing service operating at that address. Please report problems by mailing to <remail@tamsun.tamu.edu> with the subject header of PROBLEM.

Recently I had a coworker at our HQ arrange to "pull me in" to a conference call a vendor had arranged. We had a conversation about their product, after which I hung up. After I left, apparently the vendor techs all discussed the number of bugs in their product, and how glad they were that I would not be able to evaluate it for several weeks, since that gave them time to fix them.

How did I know this? My coworker noticed them still on the line, and after turning "mute" on with his phone, rejoined the conversation.

The risks are obvious. This was a computer security vendor no less!

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

Date: Sun, 05 Dec 1993 20:54:58 -0500 (EST) From: Saul Tannenbaum <saul@hnrc.tufts.edu> Subject: Apple Computer Distributes a CD-ROM with a "Trojan Horse"

Apple Software Dispatch is Apple Computer's new way to buy application software. They send you a CD (mine came unsolicited in the mail, but there are ads for it in MacWeek, etc.). You run an application on the CD, register your CD by a code that comes with the package, and then you can call an 800 number to purchase applications on the CD. You give them a credit card number - they give you some code number that unlocks/decrypts the application.

While the documentation nowhere says so, the registration process installs a System Extension onto your startup disk.

[Technical digression - System Extensions (sometimes called INITs), are pieces of code that execute at system initialization time that add to or modify the function of Apple System Software. They do this by intercepting calls to system routines and executing before, in place of, or after the builtin routine. This is considered a normal practice, and is used by Apple and 3rd parties extensively. A serious Macintosh configuration issue is the possibility that some set of extension conflict in some way. For example, if they intercept the same system routine , they may make the assumption that they are the only piece of code to do so. Debugging this can be time consuming - the last extension you add may uncover problems with an extension that to that time has been trusted and stable. Thus, careful Mac users are _very_ conservative about adding extensions and do things like configure anti-viral software to warn of new extensions being added.]

The documentation left me with the impression that some sort of data file with decryption keys or, perhaps, licensing information, would be left on my system, though, again, there is nothing that says that. The only warning I had was from anti-viral software, telling me that a new extension was being put in place when I ran the registration program.

Unfortunately, on my system, this extension clearly conflicted with something, rendering my disks (hard, floppy _and_ CD-ROM) unmountable. Removing the extension fixed the problem. Booting with Software Dispatch as the only extension also worked, so Software Dispatch is not inherently buggy - it just suffers from classic Mac extension conflict problems. However, since this extension is not mentioned in the documentation, there are people who are in for a rude shock. And, since the symptoms for this problem are just a dialog saying "This disk is unreadable on this Macintosh. Would you like to initialize it?", there are people who are going to waste endless amounts of time, restoring and rebuilding their disks needlessly. After they do that, if they still don't notice the Software Dispatch extension, they still won't have fixed the problem. And, if they reinstall Software Dispatch, they'll see the problem again.

I can't believe that I'm the only person to whom this has happened. While I run a fairly complex Mac, I am relatively conservative about system extensions - with one or two exceptions, the extensions I have aren't particularly funky, they're from Apple or 3rd party vendors. I expect that Apple will be suffering from real grief about this, and, regrettably, they deserve every little bit of it.

I should note that I did report this to Software Dispatch tech support. They took all the information and promised to get back to me. I'm still waiting.

Saul Tannenbaum, Manager, Scientific Computing, USDA Human Nutrition Research Center on Aging at Tufts University Internet: SAUL@HNRC.TUFTS.EDU

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

Date: 05 Dec 93 11:17:57 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: French Wiretaps

>From Reuter newswire via Executive News Service (GO ENS) on CompuServe, 2 Dec 1993:

Mitterrand Guard Says Elysee Ordered Phone Bugging

PARIS, Dec 2 (Reuter) - A former senior security guard of French President Francois Mitterrand told a magistrate on Thursday the president's office had ordered illegal buggings of journalists and politicians a decade ago, his lawyer said.

The article continues with details of the taps. Main points:

o organized by the deputy director of the cabinet;

o "computerised file" set up to process buggings in many parts of the government and also in the offices of lawyers, journalists, actors, politicians, and writers.

o A probe is now under way.

[Just what did the "computerised file" involve? Anyone with details, please contribute.]

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc

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

Date: 05 Dec 93 11:18:22 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Tokyo bank fraud

>From United Press International newswire via Executive News Service (GO ENS) on Compuserve, 3 Dec 1993:

TOKYO (UPI) -- Police arrested a former bank official and two advertising agency executives Friday on suspicion of fraud for allegedly stealing nearly $550,000 using a computer.

The article goes on to explain that the accused, Masuji Yamashita (a bank official), and Yasuo Ueno and Yoichiro Suzuki (clients) are alleged to have made 15 fraudulent computer entries transferring the equivalent of U$497,000 from Sakura Bank to the account of an advertising agency, Ken Enterprises. The fraud occurred over about a month (1 Feb to 4 Mar 93). "Yamashita reportedly moved the money from Ken's checking account to its savings account as cash deposits. Ken Enterprises used the funds to service its payable drafts."

[Seems like over-commitment to client service.]

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

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

Date: 07 Dec 93 10:49:36 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: German Radicals use Computers

>From United Press International newswire via Executive News Service (GO ENS) on Compuserve, 6 Dec 1993:

German radicals spy on ideological rivals BONN (UPI) -- German rightist and leftist radicals are spying on each other and drawing up hit lists of their respective enemies, the Spiegel newsweekly said in its latest issue. The issue that went on sale Monday sketched a frightening picture of increasingly well organized violent radicals using computer networks and undercover operations to gather and distribute information on those they consider their enemies."

The article also mentions computer-based training in how to make bombs.

[This development is important because it will bring criminal use of computers and networks to public and political attention. Unless knowledgeable people increase the pace of public education and awareness about computers and security, there will be hasty and ill-advised measures to restrict computer/network usage. Watch Germany closely in the next year or two to see the future elsewhere.

Comments from the ground in Germany, anyone? MK]

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

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

Date: 07 Dec 93 10:50:07 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: NJ credit thefts

>From Associated Press newswire via Executive News Service (GO ENS) on Compuserve, 7 Dec 1993:

NEWARK, N.J. (AP) -- Fifteen salespeople at a car dealership were charged with using the credit records of more than 450 people to steal millions of dollars. The salespeople tapped into credit reports through their computers, used the information to change the victims' addresses, and then ordered credit cards and ran up charges, Secret Service agent Peter A. Cavicchia said. They also allegedly used the credit information to obtain bank loans and cash advances."

The article goes on to say that the average theft was $7,500. Although the victims don't have to pay that amount, they do have to waste their time trying to correct their credit records. Apparently Autoland managers noticed the excessive and unauthorized use of their computers and reported their suspicions to the police.

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

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

Date: 05 Dec 93 15:50:23 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Counterfeits

>From Reuter newswire via Executive News Service (GO ENS) on Compuserve, 4 Dec 1993:

Customs Declare Counterfeiting Is Here to Stay (By Steven Heilbronner) FLORENCE, Italy, Dec 5 (Reuter) - British customs officials were puzzled to discover that the source of counterfeit Estee Lauder perfume was war-ravaged Bosnia. Puzzled, but not surprised, because in spite of recent seizures of counterfeit goods in Italy, Britain, Germany and France, European customs agents acknowledge they are fighting a war on so many fronts that they cannot win it."

The article discusses many non-computer counterfeits, but my eye was caught by the following points:

o "At Nintendo, the Japanese manufacturer of video games, executives estimate losses caused by piracy at $10 million a year."

o Companies are hiring security specialists to tackle the problem.

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

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

Date: 05 Dec 93 15:50:41 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: AIDS data stolen in Florida

[The Associated Press reported on 4 Dec 1993 that the computerized records of at least 6000 people with AIDS or HIV were stolen from the Jackson Memorial Hospital in Miami. Three PCs and several diskettes were stolen. PGN abstracting]

The article goes on with details:

o Crime discovered 15 Nov but not made public "for fear of alarming patients."

o Florida Department of Health and Rehabilitative Services currently reviewing security at county facilities and AIDS clinics.

The risk to the patients is extortion. In today's highly-charged atmosphere, being identified as HIV-positive has about the same social effect as a bubo during the Black Plague (even though in fact AIDS is not very communicable in non-intimate social contacts). I hope anyone victimized goes to the police immediately if they are threatened with disclosure of their status.

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

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

Date: Sun, 5 Dec 93 0:11:21 GMT From: mzmijews@mgzcs.demon.co.uk (George Zmijewski) Subject: Unauthorized changes of address (Re: Kuenning, RISKS-15.11 )

In UK when you move the house you ask Royal Mail to forward all letters addressed to you to your new address. You can apply for this service by post or in person. A day or two after receiving your application for redirection Royal Mail sends letter informing you that such service has been requested; this letter is clearly marked DO NOT REDIRECT, DELIVER TO ORYGINAL ADDRESS. This system was in practice 5 years ago when I used it for the first time. It is the only company which seems to understand that change of address can be requested by fraudsters. -- George Zmijewski mzmijews@mgzcs.demon.co.uk

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

Date: 05 Dec 93 11:15:04 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Massive credit card fraud

>From the Washington Post newswire via Executive News Service (GO ENS) on CompuServe, 2 Dec 1993:

Credit Scam Targets Mailboxes; 9 Postal Workers Among 40 Arrested in Washington Area Thefts (Serge F. Kovaleski / Washington Post Staff Writer)

Thousands of Washington area residents have been targeted by sophisticated scam artists who have pilfered mail from homes and post offices to get credit cards, checkbooks and information that they have used to steal millions of dollars, authorities said.

The article continues with details of the fraud, none of which will surprise readers of RISKS. Salient features:

o Thieves monitor external mailboxes on homes for weeks in wealthy neighbourhoods to steal credit cards and new cheques arriving in the mail.

o Pre-approved applications for credit cards are particularly vulnerable, since the thieves fill them out, send them in, and then intercept them shortly after postal delivery.

o The thieves impersonate bank officials to obtain personal information from victims, then impersonate the victims when they call banks for new personal identification numbers.

o Some victims have seen as much as $300,000 stolen through their accounts; the credit card companies (which is to say, all users of the cards) have swallowed the charges.

o A task force has been formed including members of "the Postal Service, the Immigration an Naturalization Service, the Drug Enforcement Administration, D.C. police and other local law enforcement agencies."

o Theft has struck hundreds of people in some neighbourhoods, and residents are organizing to repair insecure mailboxes and watch over them.

o Some residents are renting Post Office boxes.

o Current credit-card and bank fraud cost about $4 billion a year in the U.S.

Banks and credit-card providers have been reluctant to discuss security measures [trusting to the discredited principle of security by obscurity--MK]. Nonetheless, the authors note, certain changes are already being implemented:

o Some new credit cards don't work until the card owner confirms receipt [This alone will not stop the thieves, but see next point.--MK]

o To authenticate the card holder before activating the card, officials will use a personal profile, asking for previously-registered details of personal life. [This won't stop the criminals who fill out new card applications and give false information.--MK]

o The credit thieves use classical scavenging techniques: stealing all mail to learn about a victim, or dumpster diving to retrieve discarded documents with tidbits of personal information.

o Some thieves have re-recorded fraudulent information on discarded, expired cards and used them successfully.

Additional comments by MK:

At first glance, one might ask how such crimes are relevant for RISKS readers. I think we should be watching these developments because credit cards have become the most widely-used access-control tokens on the planet. Because their use is usually mediated by other people, it may not seem obvious to naive users that they are in fact using computer networks for electronic data interchange. It is when credit and debit cards are personally inserted into an automatic teller machine that the close link to computer networks should be evident to everyone.

As access-control tokens, most credit cards are weaker than debit cards. At least debit cards require manual input of a personal identification number (PIN) at all times. Why don't credit card companies require a PIN too?

In Canada, some banks send credit cards only by registered mail. This sounds good in theory, but in fact I have never been asked for identification. I have often sent a clerk to collect registered mail and parcels without any trouble at all. Holding the notification card seems to be all that is demanded by clerks at Canada Post. We must sign a register, but such signatures cannot be verified and are thus useless. Perhaps banks will be interested in requesting improved authentication measures by postal employees.

In the U.S., some credit cards include a digitized photograph laminated into the card. This technique presumably reduces fraudulent use in person, but does not yet affect use in banking machines or by phone. Photos would not stop fraud by thieves who steal application forms and create new cards, but it would help when legitimate cards are stolen.

Use of cards over the phone must be the easiest channel for abuse. Because there is no PIN, there is no authentication at all. Simply reciting a number suffices to debit the credit-card account as long as the card is currently valid. If a PIN _were_ required, how could it be recorded by the sales person without compromising the card's security? I think there should be a method for entering card numbers and PINs via touch-tone phone panel; such a system should preclude the order-taker from seeing the account number or at least the PIN. If a direct link between the customer's phone and the validation system were not feasible or affordable, an encryption routine on the receiving end could convert the transmitted PIN into a temporary, time/date-dependent version which would be unusable at any other time. This cryptogram would then be manually entered into the validation system by the order-taker.

Decisions on improving security boil down to cost and benefit, as always. As long as interest rates and card services charges are still acceptable to the victims, er, users of these services, there will be little incentive to change. I look forward to seeing a credit card company with the vision to protect its users and succeed in lowering costs as a result of lowered fraud. Then the industry will change its ways.

Michel E. Kabay, Ph.D. / Dir. of Education / Natl Computer Security Assoc.

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

Date: 4 Dec 93 01:26:43 GMT (Sat) From: Dr Peter B Ladkin <pbl@compsci.stirling.ac.uk> Subject: Lufthansa Warsaw crash - A Clarification [Voges, RISKS-15.31]

> [This echoes what Peter Ladkin contributed to RISKS-15.30, and is > included for those of you who did not go through Peter's account. PGN]

I'm afraid I disagree that this echoes my account. Although Udo may have correctly reported what the TV said, I find the account misleading. I'd like to clarify some differences.

First, `causes': the final report from the Polish authorities will be *the* legally valid document enumerating the factors. The major players are all discussing their favored candidates, but there is not unanimity. At least one candidate factor mentioned in my article has not been reported yet by the media [RISKS is sometimes first!]. It was not on Udo's list, which is a strict subset of the candidates so far. There may be more that we're not aware of yet. Factor 3 reported by Udo is a misleading statement of the braking logic.

Udo reports that Airbus `agreed to modify its control system'. I wonder. The so-called `modification' has been available as an option to operators for some time, and has been installed on delivered A320s. Airbus has already noted that this option is available to operators. This can't count as modification.

Peter Ladkin

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

Date: Fri, 03 Dec 1993 17:37:39 -0800 From: Flaviu Cristian <flaviu@cs.ucsd.edu> Subject: Reminder for DCCA-4: Fourth IFIP Working Conference

[For a full copy of the program and registration information, send E-mail to Flaviu Cristian <flaviu@cs.ucsd.edu> or dcca@cs.ucsd.edu or fax to +1-619-534-7029, or a telephone call to Keith Marzullo, +1-619-534-3729. An earlier version, with that information, is in RISKS-15.05. PGN]

DCCA-4: Fourth IFIP Working Conference on Dependable Computing for Critical Applications January 4-6, 1994 Catamaran Resort Hotel, San Diego, California, USA

Organized by the IFIP Working Group 10.4 on Dependable Computing and Fault-tolerance, in cooperation with: IFIP Technical Comittee 11 on Security and Protection in Information Processing Systems IEEE Computer Society Technical Committee on Fault-tolerant Computing EWICS Technical Committee 11 on Systems Reliability, Safety and Security University of California at San Diego

ADVANCE PROGRAM

Monday, January 3, 7-10pm Welcome Reception

Tuesday, January 4 9:00-9:15am Opening Remarks F. Cristian, General Chair G. Le Lann, T. Lunt, Program Co-chairs

9:15-10:45am Session 1: Formal Methods for Critical Systems Chair: M. Melliar-Smith (U of California, Santa Barbara, US) W. Turski, Warsaw University, Poland: On Doubly Guarded MultiprocessorControl System Design G. Bruns, S. Anderson, U of Edinburgh, UK: Using Data Consistency Assumptions to Show System Safety

11:00-12:30am Panel Session 1: Formal Methods for Safety in Critical Systems Moderator: Ricky Butler (NASA Langley, US) Panelists: S. Miller (Rockwell Collins, US), M. J. Morley (British Rail/Cambridge, UK), S. Natarajan (SRI International, Menlo Park, US), F. Schneider (Cornell U, US).

1:30-3:00pm Session 2: Combining The Fault-tolerance, Security and Real-time Aspects of Computing Chair: C. Landwehr (NRL, Washington DC, US) P. Boucher et al, SRI Intl, US: Tradeoffs Between Timeliness and Covert Channel Bandwith in Multilevel-Secure, Distributed Real-Time Systems K. Echtle, M. Leu, Dortmund U, Germany: Fault-Detecting Network Membership Protocols for Unknown Topologies

4:00-6:00pm Session 3: Secure Systems Chair: P. G. Neumann (SRI International, Menlo Park, US) J. Millen, MITRE: Denial of Service: A Perspective R. Kailar, V. Gligor, S. Stubblebine: U of Maryland, US: Reasoning About Message Integrity R. Kailar, V. Gligor, U of Marland, L. Gong, SRI: On the Security Effectiveness of Cryptographic Protocols

Wednesday, January 5 9:00-10:30am Session 4: Assessment of Dependability Chair: W. Howden (U of California, San Diego) C. Garrett, M.Yau, S. Guarro, G. Apostolakis, UCLA, US: Assessing the Dependability of Embedded Software Systems Using the Dynamic Flowgraph Methodology A. Aboulenga, TRW and D. Ball, MITRE, US: On Managing Fault-tolerance Design Risks

11:00-12:30 Panel Session 2: Qualitative versus Quantitative Assessment of Security Moderator: T. Lunt (SRI International, Menlo Park, US) Panelists: M. Dacier (LAAS, Toulouse, France), B. Littlewood (City U, London, UK), J. McLean (NRL, US), C. Meadows (NRL, US), J. Millen (MITRE, US)

1:30-3:00pm Session 5: Basic Problems in Distributed Fault-tolerant Systems Chair: F. B. Schneider (Cornell U, Ithaca, US) C. Walker, M. Hugue, N. Suri, Allied Signal Aerospace, US: Continual On-Line Diagnosis of Hybrid Faults A. Azadmanesh, R. Kieckhafer, U of Nebraska, US: The General Convergence Problem: A Unification of Synchronous and Asynchronous Systems

4:00-6:00pm Session 6: Specification and Verification of Distributed Protocols Chair: R. Schlichting (U Arizona, Tucson, US) O. Babaoglu, U of Bologna, Italy, M. Raynal, IRISA, France: Specification and Verification of Behavioral Patterns in Distributed Computations P. Zhou, J. Hooman, Eindhoven Univ, The Netherlands: Formal Specification and Compositional Verification of an Atomic Broadcast Protocol H. Schepers, J. Coenen, Eindhoven Univ, The Netherlands: Trace-Based Compositional Refinement of Fault-Tolerant Distributed Systems

6:30-10pm: Banquet; after dinner speaker: P. G. Neumann, SRI Int, US

Thursday, January 6 9:00-10:30am Session 7: Design Techniques for Robustness Chair: J. Meyer (U. Michigan, Ann Arbor, US) N. Kanawati, G. Kanawati, J. Abraham, U of Texas, US: A Modular Robust Binary Tree R. Rowell, BNR, V. Nair, SMU, Texas, US: Secondary Storage Error Correction Utilizing the Inherent Redundancy of Stored Data

11:00-12:30 Panel Session 3: Common Techniques in Fault-Tolerance and Security Moderator: C. Levitt (U of California, Davis, US) Panelists: Y. Deswartes (LAAS, Toulouse, France), C. Meadows (NRL, US) P. G. Neumann (SRI International), B. Randell (U of Newcastle upon Tyne, UK), K. Wilen (U of California, Davis, US)

1:30-3:00pm Session 8: Real-Time Systems Chair: L. Sha (SEI, Pittsburgh, US) M. Goemans, I. Saias, N. Lynch, MIT, US: A Lower Bound for Faulty Systems without Repair S. Ramos-Thuel, J. Strosnider, CMU, US: Scheduling Fault Recovery Operations for Time-Critical Applications

4:00-6:00pm Session 9: Evaluation of Dependability Aspects Chair: K. Trivedi (Duke U, Durham, US) G. Miremedi, J. Torin, Chalmers Univ, Sweden: Effects of Physical some Software Implemented Error Detection Techniques J. Dugan, Univ of Virginia, M Lyu, Bellcore, US: System-Level Reliability and Sensitivity Analysis for Three Fault-Tolerant System Architectures J. Carrasco, U Polit de Catalunya, Barcelona, Spain: Improving Availability Bounds Using the Failure Distance Concept

CONFERENCE ORGANIZATION General Chair: F. Cristian, U of California, San Diego, USA Program Co-chairs: G. Le Lann, INRIA, France, T. Lunt, SRI International, USA Local Arrangements/Publicity Chair:K. Marzullo, U of California, San Diego, USA

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

End of RISKS-FORUM Digest 15.32 ************************