The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 16 Issue 94

Tuesday 21 March 1995

Contents

o Deutsche Bahnfires continue
Debora Weber-Wulff
o Canadian Government Almost Spreads Virus
Colin Perkel
o Too high-tech...
Bob Wilson
o Reevaluating Our Trust in Computers
Cynthia P. Klumpp
o Internet: Threat or menace?
Eric Raymond
o Re: Latent risks of cost-benefit analysis
Steve Smith
David Chase
o Re: The Prodigious Manchurian
Rob Slade
Bear Giles
o Re: First "Bank" of Internet
Steve Holzworth
Rob Slade
Willie Smith
o Information Security Tutorials
Sushil Jajodia
o AMAST'95 Preliminary Programme available
Pippo Scollo
o Info on RISKS (comp.risks)

Deutsche Bahnfires continue

Debora Weber-Wulff <weberwu@cha01.tfh-berlin.de>
Tue, 21 Mar 1995 12:08:28 +0100
   [This is in response to a query from me to DWW on this subject.
   Thanks to Debora for sharing with us what she knows.  PGN]

The Deutsche Bahn AG, the German train company, has been working round the
clock for a long time to a) electrify the state of Schleswig-Holstein, which
is just north of the city-state Hamburg, and b) to install a full
computerized train regulation system. The big traintable change is scheduled
for next Sunday (March 26), when the daylight time change takes effect, I
believe.  They went on-line with the regulation system last week and all
h*** broke loose.  It was okay for the first few hours, and then suddenly
went berserk.  I don't have all the details, as I have only listened to
radio news the past few days, but they ended up having to route all traffic
around this major switching point. The train station in Hamburg Altona,
where the diesel locomotives are removed and electric ones put on for
continuing trains, or where most people just have to change trains, was put
out of service. People had to take the S-Bahn or a bus to the main train
station, and ended up missing connections.  (And then we have the problem
with the local trains being fuller than Indian trains because of a special
super-cheap deal on weekends, but that's another and computer-unrelated
story.)

I do not know for certain if Siemens is the main manufacturer, but I suspect
that it is them together with AEG. They just founded a company together with
ABB in Sweden to combine all their rail knowledge. Yes, they subcontract out
a lot, some to a little company in Kiel, a bunch to Third-World company (but
this is just rumor). How could this pass the testing phase? Well, this is
not the first time Siemens has boo-booed (remember the microphone system in
the Bundestag? There have been many others). My personal opinion is that
Siemens/Sietec does not have control of their Quality Assurance and there
are too many programmers there that believe that they can do no wrong, and
bosses who believe them, because it costs too much to actually do massive
testing. German programmers tend to take it as a personal insult when a
fault is detected in code that they have written. Companies like
Siemens/Sietec exacerbate the situation. I repeat, this is my personal
opinion based on unscientific surveys conducted during drinking and card
playing sessions.... so nothing eminently quotable.

There should be an article in Computerwoche (German language) soon about it
when the CeBit smoke clears, they enjoy reporting about Siemens/Sietec
disasters. I'll keep an eye out for more details.

Debora Weber-Wulff  weberwu@tfh-berlin.de


Canadian Government Almost Spreads Virus

Colin Perkel <colin.perkel@guildnet.org>
Tue, 21 Mar 1995 17:46:09 -0500
   The Canadian government's first attempt at electronic distribution of its
budget last month could have created havoc -- but not because of the
measures it contains.  A virus was discovered about an hour before more than
5,000 disks containing budget information were to be sent to the country's
major financial institutions.  One expert is quoted as saying the situation
could have been catastrophic for banks etc.

   The RCMP are investigating how the unnamed virus (said to be boot-sector
or FAT destructive) had found its way onto the master disk being used to
make copies. The master had passed two Revenue Canada virus scans but a last
minute check by the company hired to do the copying and distribution turned
up the critter.

   Given the super secrecy and security surrounding the budget, there are
serious questions as to how this could have happened. The RISKS involved in
the federal government spreading viruses are obvious!


Too high-tech...

Bob Wilson <wilson@math.wisc.edu>
Tue, 21 Mar 95 09:23:21 CST
I just heard on the radio an announcement of a new safety project for
farmers. Farming is one of the most hazardous occupations, by usual
measures, with a significant number of injuries and fatalities happening
when farmers get off of a tractor or similar piece of equipment to do a
brief task like untangling something, but leave the equipment running. The
proposed fix? Use the GPS satellite location system, which will be used by a
piece of equipment worn by the farmer and another on the tractor: When they
move apart, the tractor gets turned off.

I suspect "the risks are obvious", as well as the availability of MUCH
simpler technologies to do the distance sensing if in fact that is a good
thing to do....

Bob Wilson  wilson@math.wisc.edu

   [This sounds almost as far-fetched as the completely computerized
   SUNDIAL I conjured up for an editorial in the ACM Software Engineering
   Notes many years ago, as an example of technological overkill.
   Ultimately, the sundial would have used GPS to provide automatic dynamic
   seasonal corrections dependent on longitude and latitude, would track
   its own movement (no pun intended), and would work at night by simulated
   sunlight.  PGN]


<"cklumpp1@vaxa.hofstra.edu"@vaxc.hofstra.edu>
Mon, 20 Mar 1995 20:21:24 -0400 (EDT)
Subject: Reevaluating Our Trust in Computers

Computers have, in most cases, improved the overall quality of life for us.
When a computer process goes smoothly we are amazed at the speed and
accuracy of the machine.  But when something goes wrong, it is human nature
to want to place the blame upon someone or something.  When the problem is
minor we can usually laugh it off or write it off as a "computer error",
whether or not this is actually true.  But, when the problem has caused
severe (life-threatening) consequences we need in depth explanations of
accountability.

Also, the number of people affected by computer errors can range from one
person who is directly involved in the use of the computer - to many people
who are innocent bystanders.  If the operator is the only one inconvenienced
by a computer error assuming it created a minor problem, blame can be
shrugged off.  While at the other extreme, if large numbers of people are
affected by the error, blame is sought.

Therefore, there are two determining factors which cause us to want to place
blame for the occurrence of computer errors.  One factor is the severity of
the problem and the other one is the number of people affected.

With the increasing involvement of computers in our daily lives the number
of errors occurring is also increasing.  Errors seen many times in the past
are still occurring while new errors are cropping up with the use of new
technology.  The dependent relationships between the software, hardware,
data input (whether it is by a person or computer generated), procedures,
and the communication links [risks-9.61], create a very complex environment.
The blind trust we have in computers and the people who operate or program
them may need to be reevaluated.  In other words, can and should we always
trust a computer operator or a computer with the ever increasing processing
of data which affect our lives and then look to blame when failure occurs?
Or should we decrease or adjust the trust we place on data input and
computers?

While I was doing a search for articles at the library on the periodical
database and happen to be short of time one night, the computer froze
suddenly for no apparent reason.  I had already spent 30 of my precious 90
minutes reading abstracts and marking (to print) the ones I thought were
relevant.  I had not yet printed the abstracts when the computer stopped
responding to keystrokes.  I asked the reference librarian if there was
anything that could be done.  He said "Not usually, but try [Ctrl] Z or
[Ctrl] [Enter]."  I did - but nothing happened.  He shrugged.  I shrugged
and laughed, then moved over to another machine to start my work all over
again...how fitting.  I would not have enough time to make copies of the
articles I searched for and would have to return another day.

I probably should not have trusted the computer to get me smoothly through
my work that night; I left no time for computer error expecting the computer
to be 100% reliable.

Cynthia P. Klumpp  cklumpp1@vaxc.hofstra.edu


Internet: Threat or menace? (Mills, RISKS-16.93)

Eric Raymond <esr@netaxs.com>
21 Mar 1995 15:24:55 GMT
In a recent comp.risks post, Dick Mills speculates that the stability of
civilization up to now may have depended on the ineffectiveness of
one-to-many communication, and that the Internet condemns us to drown in
memetic garbage generated by kooks, fanatics, and evangelists.

I suggest Mr. Mills think of it as evolution in action.  The people -- and
civilizations -- that survive will be those who learn and teach critical
reading and thinking skills.  This is strictly analogous to the selection
effect of biological plagues.

Eric S. Raymond


Re: Latent risks of cost-benefit analysis (Smith, RISKS-16.93)

Steve Smith <sgs@access.digex.net>
21 Mar 1995 14:32:28 -0500
The risks of cost-benefit analysis that I see are more direct.  First, in
order to do a cost-benefit analysis, you have to make assumptions about
relative values.  It is totally impossible to do this in a
politically-neutral way.  Consider, say, a C-B analysis of a wetland
development done by a real-estate developer and and the same analysis done
by Greenpeace.  No way are they going to be similar.

Second, C-B analyses are trotted out as some kind of Gospel.  Somebody comes
up with the numbers, lawmakers or bureaucrats make decisions, and the public
is stuck with the results.  What if the analysis is wildly off?  Where is
the responsibility?

I would like to see the organizations who do these analyses post a bond.
Won't happen, but it's interesting to think about.

Steve Smith                     Agincourt Computing
sgs@access.digex.net            (301) 681 7395


Re: Latent risks of cost-benefit analysis (Smith, RISKS-16.93)

David Chase <chase@centerline.com>
21 Mar 1995 14:59:46 GMT
[...] Or more generally, cost-benefit analysis skews in favor of what can be
"measured" (medical costs, property values, paycheck) at the expense of the
"intangible" (freedom, nice-smelling air, peace of mind, a good day fishing,
national security, employee loyalty).

Where social benefit is easily measured, it skews towards social benefit.
Where social benefit is not easily measured, it skews away.  I can well
imagine a statistical arms race between the two sides of any costly policy,
attempting to assign value to the otherwise intangible costs and benefits of
the policy.  It's also an entertaining game to see what intangibles are
considered so important that they should not have a price tag attached (and
by whom).

David Chase  CenterLine Software


Re: The Prodigious Manchurian (Garfinkel, RISKS-16.93)

"Rob Slade, Social Convener to the Net" <roberts@mukluk.decus.ca>
Tue, 21 Mar 1995 13:23:45 EST
In a recent posting, Simson Garfinkel used a reference to Prodigy's former
method of handling swap space to point out that certain types of online
access systems leave you vulnerable.  In today's issue, Frank Ferguson tries
to indicate, using details of the MS-DOS FAT and delete function, that such
a concern is invalid.  They are, or course, both right, but Garfinkel is
righter.

While Prodigy never did have any specific function in their software to
browse and return information from the user's computer to the company, the
software did have provisions to automatically update software.  This could
(although it wasn't) be used to run other types of software without the
user being aware of it.  But we don't have to pick on Prodigy.  Other
commercial systems "take over" your machine when you run the front end
software.  This is, of course, done to ease the burden of use for the
subscriber, but it does mean that the online service can basically do
anything they want with your computer.  (The same, of course, is true for
any software, but commercial online systems have the advantage of being
in communication with their own software while it is running on your machine.)

We need not limit the discussion to commercial services.  GUI (graphical
user interface) systems tend to have a lot of security loopholes and hiding
places anyway.  The X system has provisions for a remote system to control
your workstation.  The various World Wide Web browsers, particularly the
graphical ones like Mosaic, have the ability to both transfer files and
invoke execution of programs.  That's all you need for a really nifty
virus/worm ...

DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733


Re: The Prodigious Manchurian (Garfinkel, RISKS-16.93)

Bear Giles <bear@tigger.cs.colorado.edu>
Mon, 20 Mar 1995 22:18:44 -0700
I content that this behavior *is* a bug.  The proof is in the public's
reaction to finding bits of "their" files in the Prodigy cache area.

To give a human metaphor, imagine a coworker who casually leafs through the
papers on your desk while waiting for you to get off the phone.  This might
be nothing more than a nervous mannerism and he may be totally unaware of
what he's doing, but very few people won't be seriously annoyed at him.

To avoid even the appearance of impropiety, most people carefully stare
into space (or read a magazine) in this situation.

Prodigy didn't observe this behavior (which in the computer world would have
been allocating the space and immediately wiping the current data); it
grabbed some disk space and saved a few seconds by not wiping the existing
data...

... and found itself tremendously embarrassed because it violated one of the
prime rules of our society (regarding privacy).  The fact that we're still
discussing this years later proves how sensitive of a nerve it hit!

In an era when computers were scarce resources and few people had frequent
interactions with one, such behavior could be justified as a valid
engineering tradeoff.  But computers are now routinely used by a large part
of the population, and it is incumbent on the programmer to observe the
social conventions even if it proves to be moderately "expensive."

Bear Giles  bear@fsl.noaa.gov


Re: First "Bank" of Internet (Beigh, RISKS-16.93)

Steve Holzworth <sch@unx.sas.com>
Tue, 21 Mar 1995 16:23:44 -0500
This "announcement" is so full of holes as to be ludicrous.

1) According to the NC Banking Commission, use of the term "bank", with a
    very few limited exceptions, is illegal for anyone but an organization
    that is a federally (FDIC) or state chartered, regulated entity. The NC
    Banking Commission has taken an interest in this announcement, and is
    forwarding the info to the FDIC...

2) "The alternative to personal credit cards for electronic commerce is
    based on an FBOI procured Visa (tm) Automated Teller Machine (ATM) card.
    The card is prepaid, PIN protected, replaceable, disposable, and good
    at over 200,000 Visa/PLUS (tm) ATMs in 83 countries.  "

Translation: 'you send us $x.xx to keep on account (with no interest accrued
to you). We deduct purchases from this balance'. What happens if we disagree
on the balance and/or dispute transactions? Because this an ATM card as
opposed to a credit card, normal fraud liability limitations ($50.00 US)
and disputed charge reversals are not in effect. If someone fraudulently
charges against your ATM account, you potentially bear the full loss.

Also, the "vendor" info, sent in response to the specified E-mail request,
indicates that the ATM cards are not "rechargeable". When you run your
balance down, you must buy a new one. FBOI charges a 5% commission to
establish a new card for you (ie - the "setup" fee is 5% of the balance you
wish to put on account; when that runs out, you pay another 5% for a new
card).  Since they charge vendors a 5% commission per transaction, FBOI is
keeping 10% of all funds that move through their system.

3) "The safety of FBOI is ensured because access to ATM funds without
   possession of both the ATM card and the Personal Identification Number
   (PIN) is not possible.  ATM cards are also better than credit cards because
   their purchase does not require the personal, financial, and employment
   background of the consumer."

Here is how a transaction is instigated (from FBOI info):

   "*FBOI procedures for creating a vendor E-mail invoice*
    FBOI E-mail invoices are a two line message created by a FBOI vendor.
    Line one of the message contains the customer Internet E-mail address.
    Line two contains the transaction amount in US dollars.  This message
    must then be encrypted, signed, in ASCII, and in Text using the PGP
    command "PGP -seat invoice fboi".  The "invoice.asc" is then ready to
    be E-mailed to fboi@netcom.com with subject "invoice".  FBOI will issue
    an E-mail transaction receipt."

    "*FBOI procedures for creating a customer E-mail check*
    FBOI E-mail checks are a two line message created by a FBOI customer.
    Line one of the message contains the vendor Internet E-mail address.
    Line two contains the transaction amount in US dollars.  This message
    must then be encrypted, signed, in ASCII, and in Text using the PGP
    command "PGP -seat check fboi".  The "check.asc" is then ready to be
    E-mailed to fboi@netcom.com with subject "check".  FBOI will issue an
    E-mail transaction receipt."

FBOI then reconciles the above transactions and sends payment to the vendor
(or credits the vendor's ATM card). Note that FBOI recommends product pricing
at around ONE US DOLLAR for items! (Almost-Freeware, anyone?)

4) "...In addition, consumers can reclaim their funds at any time using
    an ATM."

At what service charge per transaction? What limitations on withdrawal
amounts (how many transactions will it take to empty my account)? Any
yearly fees for this privilege? FBOI info is rather vague in this regard.
The only pertinent comment I saw was (pertaining to vendor payment):

    "... While the Visa ATM card as a payment method has many
    advantages (portable, anonymous, and cash in any country of the world),
    your ATM may not dispense the entire payment due to the exchange rate
    and possible ATM fees."

5) "...Those services will collect the consumers credit card information in
   advance because of Internet security problems."

Since those are still credit card transactions, the consumer has much better
dispute resolution abilities.

6) "FBOI transmits no sensitive information over the Internet and prevents
    forgery and impersonation by using Pretty Good Privacy, PGP (tm),
    software for all transactions.  This freeware provides excellent
    authentication and anti-alteration security."

The description of transactions as in (3) above may or may not be subject
to spoofing. I'm not up enough on crypto to comment.

7) "In addition to the unsecured nature of the Internet, consumers should be
   hesitant giving out their credit card information to vendors of unknown
   credibility."

You mean like FBOI?? Based out of a Netcom account (instead of a .com domain)?

8) "...since U.S. Postal Service and Federal Trade Commission mail order laws
    do not apply to the Internet."

The laws may not apply to the Internet per se, but credit card transactions
are still subject to all of the controls of typical "mail order" as is
normally practiced via telephone.

9) "The First Bank of Internet (tm) is not a lending institution, and is not
    chartered."

This says volumes.... (see (1), above).

And finally:

    "When FBOI procures a Visa ATM card for vendor customers the card
    becomes their money.  FBOI will be granted access to their funds
    through the FBOI customer agreement allowing FBOI to possess a
    duplicate card."
 ^^^^^^^^^^^^^^^^^^


Re: First "Bank" of Internet (Beigh, RISKS-16.93)

"Rob Slade, Social Convener to the Net" <roberts@mukluk.decus.ca>
Tue, 21 Mar 1995 13:50:53 EST
The FBOI card does seem to address some of the security concerns for commerce
over the net.  The replacement of one number by another does not provide
any particular safety, but the limit on the card does restrict the damage.
However, inquiring minds want to know:

How easy is it, aside from emptying the account, to cancel/change/get a new
card?  Is there a fee?  Is there any recourse if someone empties the account
before you do?

Does the encryption apply only to the card number, or to the whole transaction,
including time and date stamp?

Does the encryption software come with the card?  Is it a smart card?  Do
you need a card reader of some type?  What platforms is the software available
on?  Is the user responsible for getting/setting up the software?

By using PGP is the FBOI restricting its operations to the US?  Is the
version of PGP that they are using operating with the RSA algorithm, or
another?  Is the key size restricted?

If this really does work over E-mail, why do you keep talking about ATM?
(Does it only work over asynchronous transfer mode networks?  :-)

DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733


Re: First "Bank" of Internet (Beigh, RISKS-16.93)

Willie Smith <wpns@roadrunner.pictel.com>
Tue, 21 Mar 1995 08:15:38 -0500 (EST)
In Risks 16.93, fboi@netcom.com (Vinn Beigh) writes:
>The card is prepaid [...]
>The safety of FBOI [the non-chartered, non-bank company] is ensured

...by the fact that it's prepaid, and even if FBOI loses all the money
in the account due to fraudulent transactions, it's _your_ money
that's gone, not their 5[!!] percent!

>The worldwide producers on the Internet can use FBOI services without the
>expense of owning or renting a dedicated Internet server or a World-Wide
>Web site.

Yeah, just get an account on netcom and you're a business!  C00L!

>In addition to the unsecured nature of the Internet, consumers should be
>hesitant giving out their credit card information to vendors of unknown
>credibility.

Giving cash to some guy with a Netcom account is OK?  Maybe I missed
the smiley, or the original submission was tongue in cheek...

>since U.S. Postal Service and Federal Trade Commission mail order laws
>do not apply to the Internet.

Another safety net for FBOI.  What a gig!  Tell you what, I now announce the
First International Bank Of The Information Supercollider, you send me money
and I promise not to lose it.

                            [The money, that is, not the Supercollider. PGN]

Willie Smith    wpns@pictel.com     N1JBJ@amsat.org


Information Security Tutorials

Sushil Jajodia <jajodia@isse.gmu.edu>
Mon, 20 Mar 95 10:28:42 EST
                INFORMATION SECURITY INSTITUTE
                        Sponsored by:
              Center for Professional Development
                    George Mason University
                    Fairfax, VA 22030-4444

Intensive, Short Courses:

o  Information Security Principles and Practice  March 27-31, 1995
   Instructors:  Marshall Abrams, Daniel Gambel, Sushil Jajodia,
     Harold Podell, Ravi Sandhu

o  Recent Developments in Information Security   March 27-31, 1995
   Instructors:  Marshall Abrams, Daniel Gambel, Sushil Jajodia,
     Harold Podell, Ravi Sandhu

o  Practical Security in a Networked Environment  April 3-7, 1995
   Instructors:  Marshall Abrams, Ravi Ganesan, Sushil Jajodia,
     Brian McKenny, Harold Podell, Ravi Sandhu

o  UNIX Security  April 3-7, 1995
   Instructors: Marshall Abrams, Ravi Ganesan, Harold Podell, Ravi Sandhu

For further information, visit the Information Security Institute home
page through mosaic at http://www.isse.gmu.edu/~gmuisi.


AMAST'95 Preliminary Programme available

Pippo Scollo <scollo@cs.utwente.nl>
Mon, 20 Mar 1995 16:50:49 +0100
The Preliminary Programme of the AMAST'95 Conference (4th International
Conference on Algebraic Methodology And Software Technology, Montreal,
Canada, July 3-7, 1995) is available on the WWW at the following URL:

  http://www.cs.utwente.nl/data/amast/amast95/PreliminaryProgramme.txt

The file includes abstracts of the invited talks, conference schedule,
registration information and registration forms, and accommodation and
travel information. The deadline for reduced registration fees is:

  Monday June 5, 1995

The file is also available by anonymous ftp:

  host:      ftp.cs.utwente.nl
  username:  anonymous
  password:  your E-mail address
  directory: pub/doc/amast/amast95/
  get file:  PreliminaryProgramme.txt

More information about AMAST'95 is available from the following sources:

 1. For bulletins on current status of the conference:

    amast95-info@cs.concordia.ca
    Tools and Demos: grogono@cs.concordia.ca
    Registration: krishnan@cs.concordia.ca
    Local Arrangements: missaoui.rokia@uqam.ca

 2. For subscribing to AMAST'95 mailing list:

    amast95-request@cs.concordia.ca

Please report problems with the web pages to the maintainer

Top