The RISKS Digest
Volume 15 Issue 32

Tuesday, 7th December 1993

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


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

FAX sends instead of receives

John McKay <>
Tue, 7 Dec 1993 16:56:43 -0500
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]

Risks of conference calls "lack of announcement"

Tue, 7 Dec 93 10:55:38 -0600
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
    <> 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!

Apple Computer Distributes a CD-ROM with a "Trojan Horse"

Saul Tannenbaum <>
Sun, 05 Dec 1993 20:54:58 -0500 (EST)
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

French Wiretaps

"Mich Kabay / JINBU Corp." <>
05 Dec 93 11:17:57 EST
>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

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

Tokyo bank fraud

"Mich Kabay / JINBU Corp." <>
05 Dec 93 11:18:22 EST
>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

  [Seems like over-commitment to client service.]

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

German Radicals use Computers

"Mich Kabay / JINBU Corp." <>
07 Dec 93 10:49:36 EST
>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.

NJ credit thefts

"Mich Kabay / JINBU Corp." <>
07 Dec 93 10:50:07 EST
>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
    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.


"Mich Kabay / JINBU Corp." <>
05 Dec 93 15:50:23 EST
>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.

AIDS data stolen in Florida

"Mich Kabay / JINBU Corp." <>
05 Dec 93 15:50:41 EST
  [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.

Unauthorized changes of address (Re: Kuenning, RISKS-15.11 )

George Zmijewski <>
Sun, 5 Dec 93 0:11:21 GMT
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

Massive credit card fraud

"Mich Kabay / JINBU Corp." <>
05 Dec 93 11:15:04 EST
>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

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

o    Some residents are renting Post Office boxes.

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

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

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.

Lufthansa Warsaw crash - A Clarification [Voges, RISKS-15.31]

Dr Peter B Ladkin <>
4 Dec 93 01:26:43 GMT (Sat)
>   [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

Reminder for DCCA-4: Fourth IFIP Working Conference

Flaviu Cristian <>
Fri, 03 Dec 1993 17:37:39 -0800
  [For a full copy of the program and registration information, send
  E-mail to Flaviu Cristian <> or
  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


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
    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
  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

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

Please report problems with the web pages to the maintainer