University of Bielefeld -  Faculty of technology
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D.
Back to Abstracts of References and Incidents Back to Root
This page was copied from: http://catless.ncl.ac.uk/Risks/16.05.html


Previous Issue Index Next Issue Info Searching Submit Article

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 5

Weds 11 May 1994

Forum on Risks to the Public in Computers and Related Systems

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

Contents

o Are we betting on horses or computers? (off-track betting)
Reva Freedman
o Amusing computer-related anecdote about local cable service
H Morrow Long
o MTV Sues Curry
Adam Curry
o China Airlines A300 Crash
Mark Stalzer
o Re: Elevators, Car bumpers and Cryptography...
Peter Wayner
o Re: Bellcore cracks 129-digit RSA encryption code
Fred Cohen
Amos Shapir
o Re: ACM Nightline
Robert Morris
o Don't always believe those E-Mail addresses
A. Padgett Peterson
o EFF's Kapor announces new cyberspace TV show
Kapor via Stanton McCandlish
o Automation: request for input
Ken Funk
o Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
---------------------------------------------

Are we betting on horses or computers? (Risks of off-track betting)

<freedman@merle.acns.nwu.edu>
Tue, 10 May 94 15:46:02 CDT
     
     Illinois has off-track betting on horse races. You can place your bet at
     one of these legalized bookie joints, then watch the race on TV and
     collect your winnings. If you place your bet early in the day, you don't
     even have to wait around for the race. You can watch the race at home and
     come back later to collect. That's the theory, anyway.
     
     On Saturday, April 23, the computer system handling the betting for some of
     the remote sites crashed after the fourth race. People at the betting parlors
     were told that they couldn't place any more bets. But what about those who had
     placed their bets and left? When winners returned on Sunday to collect, they
     were surprised to learn that, from the racetrack's point of view, they had
     never placed a bet, and were offered only a refund of the cost of their
     ticket.
     
     So were losers, if they had kept their tickets and happened to hear about the
     computer crash. However, the fact that refunds were available was not listed
     in the newspaper with the race results, mentioned on the telephone hot line,
     or mentioned on cable TV broadcasts of the races.
     
     On Monday a class-action lawsuit was filed. By Tuesday, racetrack management
     had decided to pay up.
     
     The system, designed by Amtote International, had only been in operation for a
     month. On the other hand, state officials had sued Amtote before for
     deficiencies in the previous system. No description was given of the original
     failure, but newspaper reports (Chicago Tribune, 4/26/94 and 4/27/94) said
     that a hardware problem caused the backup system to fail.  The new system was
     designed to be "user-friendly." I hate to say it, but the most user-friendly
     component in this incident was the lawyers!
     
     Reva Freedman  freedman@merle.acns.nwu.edu
     
     
---------------------------------------------

Amusing computer-related anecdote about local cable service

H Morrow Long <long-morrow@CS.YALE.EDU >
9 May 1994 17:21:07 -0400
     
     A very interesting program was on Storer cable channel 70 last night [they
     call themself Comcast now, and serve the areas of West Haven, New Haven, and
     Hamden].  For a long time, only the following message was flashing at the top
     of the screen:
     
      ----------------------------------------------------------------
      | Software Failure.      Press left mouse button to continue.  |
      |           Error:  0000 0003  Task:  002006f0                 |
      ----------------------------------------------------------------
     
     Talk about having your software problems out where the world can see them.
     Didn't look like anyone was minding the store(r).  I guess someone there had
     to press the left mouse button this morning...
     
     H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT
     06520-8285,  (203)-432-{1248,1254}  Long-Morrow@CS.Yale.EDU 
     
        [In the old days, it was not unusual for a mouse to nibble into
        a cable.  Now we have cable nibbling at the mouse.  Turn(er)about 
        is fare prey.  PGN]
     
     
---------------------------------------------

MTV Sues Curry

Adam Curry <curryco@panix.com >
10 May 1994 03:44:36 -0400
     
                                  [IMAGE] MTV SUES CURRY
     Last update: May 10 1994
     _New Jersey, May 10 1994_
     
     I had planned to keep the following quiet until more information was available,
     but since several journalists have already caught wind of it, I decided to get
     it out into the open so my side of the story is heard as well.
     
     The domain I maintain and operate on the Internet, mtv.com was founded
     approximately one year ago. At that time I registered mtv.com with the
     InterNIC, purely because it was a cool address to have, and it was available.
     What a great "vanity plate"!
     
     The site quickly became a frequently accessed "hangout" on the net, with an
     average of 35000 accesses daily from Mosaic clients alone. During the start up
     months I had many conversations with executives at MTV Networks about my
     endeavours, which btw, were all financed out of my own pocket, and vps from MTV
     Programming as well as Viacom New Media were aware of what I was doing on the
     internet, and although they stated "MTV has no interest in the internet" they
     gave me their blessing and supported my efforts.
     
     This was enforced when I set up several email accounts on mtv.com for use in
     MTV's on-air programming. Ever since the summer of '93, popquiz@mtv.com was
     used for trivia quiz questions, that were then aired on MTV's "Most Wanted" a
     program I hosted at the time. Solicitations were made on the air, and the
     address was shown on the screen. For MTV's annual Valentines video dedications,
     viewers were offered the choice of calling in their dedications, or sending
     them via email to elove@mtv.com.
     
     I never charged MTV Networks for this service, I purely saw it as a cool
     feature to introduce to MTV's programming, spreading the "gospel", so to speak.
     
     
     Then I started to get a lot of press about mtv.com, and some people started to
     wake up at 1515 Broadway (MTV's HQ in New York City). And I was served with a
     "Cease and desist" on the use of mtv.com. MTV's attorneys claimed that there
     could be "confusion" for users of the internet, when connecting to *anything*
     that had the letters mtv in the address, and then receiving music and
     entertainment information. I was obviously hurt by this move, but did see what
     point they were driving at, an asked if we could settle this matter amicably.
     
     The situation cooled down for a couple of months, but when I resigned on-air
     from my job as a VJ, which MTV chose not to air btw, things started to get
     ugly.
     
     Long story short, MTV Networks has filed a lawsuit against me, for copyright
     infringement of their "trademark", that being their "MTV" call letters, as
     well as having information online that was MTVN "property". In this case they
     are referring to several press releases I put up on mtv.com, such an
     announcement about Beavis and Butthead's "experience" cd release. Understand
     that MTVN sent me these releases over their own internal computer network for
     this very purpose! Again, I was only doing this to promote the channel, not
     for my own personal gain..after all...mtv.com is free access for all, no
     charge.
     
     Throughout all of this I have offered to maintain the site specifically for
     mtv, but again they said "we're not interested". Of course, I have no problem
     whatsoever removing all references to MTV Networks and it's projects from
     mtv.com, no that I don't work there anymore gives me even more reason to want
     to do this, but the kicker is they are moving for an injunction to make me
     stop using the internet address mtv.com!
     
     This is of course totally unacceptable: I registered the domain name, and I
     don't plan on giving it up. Sure MTV and their parent company Viacom have a
     vast legal team, but david also nailed goliath, so I have faith. In the long
     run, everyone knows that the only *true* winners will be the lawyers.
     
     There are many different viewpoints on this situation, but I feel that the use
     of mtv in an addressing scheme can't be seen as an infringement of
     intellectual property laws, and a search of the InterNIC database shows at
     least 15 domain names registered with mtv in the address. Irony is that I
     incorporated a company called ON RAMP, Inc (tm) and onramp.com was already
     registered to someone else, but I'm not suing them :)
     
     It appears to me that MTV has their mind set on the address mtv.com, maybe not
     for now, but possibly for future use, and I feel extremely used, in that I
     built up quite an audience for that address, and they are basically saying
     "thank you very much, you may go".
     
     A pre-motion hearing is scheduled for this thursday morning at 11am, wit the
     honourable Judge McKenna presiding, in an attempt to get an injunction to make
     me stop using the address mtv.com. I will update the situation as it unfolds.
     
     Adam Curry, adam@mtv.com
     
     
---------------------------------------------

China Airlines A300 Crash

<stalzer@macaw.hrl.hac.com>
Wed, 11 May 1994 09:02:33 +0800
     
     The L.A. Times today (May 11) published a story on the A300 crash last month
     at Japan's Nagoya airport. I'll quote the first paragraph and then summarize
     the remainder of the story.
     
     "A terrifying battle between an inexperienced co-pilot and his airplane's
     super-sophisticated computer system preceded last month's crash of a Taiwanese
     jetliner that killed 264 people..."
     
     The events described in the rest of the article are as follows:
     1. The plane was being hand-flown on approach to landing by
        its 26-year-old copilot.
     2. About 2 minutes prior to landing, the A300 went into
        "go-around" mode for reasons unknown.
     
     3. Even though the pilot warned the co-pilot 3 times in 30 seconds, as
        recorded by the voice recorder, the co-pilot continued to attempt to land 
        the plane. The effect was that the auto-pilot was trying to pitch the 
        nose up using the "horizontal stabilizer flaps" while the co-pilot was 
        trying to pitch the nose down using the "elevator flaps" (the Times 
        author might have this a bit confused).
     4. The crew then switched the "go-around" mode off. However, the "stabilizer
        flaps remained set at a sharp angle."
     5. The crew realized the plane was too high to land, so they set the 
        "go-around" mode back on.
     6. This caused the plane to climb sharply and approach a stall.  The A300 
        stall-prevention system automatically increased the engine thrust but 
        this INCREASED the climb angle to 53degs.
     7. The airplane stalled.
     8. The nose dropped and the airspeed increased to 150mph at an altitude of 
        260 yards.
     9. At this point, the entire electrical system stopped functioning
        for reasons unknown, including the flight data and voice recorders.
     10. The plane crashed, killing 264 people. There were 7 survivors.
     
     The root cause of this crash seems to be a confused co-pilot. However, the
     A300's automatic systems contributed in two ways.  First, it continued to
     attempt the go-around even though the plane was still being flown by hand. Had
     the auto-pilot disengaged (with a suitable warning!) this whole disaster may
     have been adverted.  I think a human supplying control inputs is the "final
     authority" and the automatic systems should "back off".  Second, the
     stall-prevention system's actions (increasing thrust) contributed to the
     stall. This is a serious kind of failure, if a automatic system designed to
     prevent a problem makes it worse, it should do nothing at all!
     
       -- Mark Stalzer (stalzer@macaw.hrl.hac.com)
     
     
---------------------------------------------

Re: Elevators, Car bumpers and Cryptography...

Peter Wayner <pcw@access.digex.net >
Tue, 10 May 1994 15:37:05 -0400
     
     I once talked to a major elevator company about doing just what the Schindler
     Elevator Corp. is accused of doing by the Toronto government. (RISKS-16.04).
     The company told me that they were in the habit of selling the elevators at a
     loss so they could make up the money in service contracts. Then they found
     themselves battling independent service companies who undercut their prices.
     They hoped to use cryptography to lock out any other service provider without
     the right key.
     
     Of course, this loss-lead approach is common in many businesses. Car companies
     often sell their cars at a low price and hope to make it up selling spare
     parts later. That is why I discovered that a spare bumper for my car cost over
     $500.
     
     The difference is that other companies are now making duplicate parts.  The
     major automakers can try and discourage them, but they can't lock them out of
     the business.
     
     Cryptographic locks, though, are a different story. They probably can't be
     broken in a reasonable amount of time. (See also 16-04) I'm not sure of the
     case law on this, but I would suspect that it might fall under questionable or
     illegal trade practices. At least in the US.
     
     
---------------------------------------------

Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04)

Fredrick B. Cohen <fc@Jupiter.SAIC.Com>
Tue, 10 May 94 19:33:36 PDT
     
     I think a lot of people are missing the real point about the RSA.  On my
     pocket PC, I can create a code that requires 5,000 MIP years to break in a
     matter of seconds.  If I am willing to use several more seconds, I can make a
     code that takes 10^25 MIPS years to break.  Compare this to any other
     encryption scheme, and you will find that the workload amplification of the
     RSA is quite good.
     
     And Shannon told us in 1949 that any non-perfect information transform can be
     broken with enough cyphertext - and developed the concept of workload for
     evaluating cryptosystems.  If we want perfect cryptosystems we know how to get
     them, but it requires secure distribution.  On the other hand, the RSA
     provides any degree of complexity we wish to generate (finite) and a fantastic
     complexity amplification factor, and the advantages of a dual public key
     system that can be used for both encryption and authentication.
     
     The point is that the RSA has not been broken, rather it has shown just how
     much of a David is required to defeat a given Goliath.  After all, in terms of
     that story, David would have been a MIP second and Goliath 5,000 MIP years in
     relative sizes for a break-even fight.  I'll take that David any day.  FC
     
     

Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04)

Amos Shapir <amos@CS.HUJI.AC.IL >
11 May 1994 15:19:01 GMT
     
     > So where does the 40 quadrillion figure come from?
     
     It comes from this very table. 10^9 is a billion, not a trillion, in the US
     system, and 40 quadrillion is 4 x 10^16, which is even less than what I get by
     interpolating to 425 bits (can anyone who has access to the original RSA
     article verify this?).
     
     There seems to be an interesting risk here: most encryption methods rely on
     "hard" problems, i.e. problems whose "brute force" solutions require
     computation resources which are an exponential function of the key length.
     But in a world in which computing power grows exponentially, such problems can
     be solved in polynomial (or even linear) time!
     
     Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science.
     Givat-Ram, Jerusalem 91904, Israel  +972 2 585706,586950  amos@cs.huji.ac.il
     
     
---------------------------------------------

Re: ACM Nightline (Kabay, RISKS-16.03)

Robert Morris <ram@cs.umb.edu>
Wed, 11 May 1994 10:09:00 -0400
     
     >...they have _no right_ to use the product without that contractual agreement.
     
     This confuses several issues--that of theft, that of use and that of
     licensing, and in an important case Kabay's implied position is wrong.
     Certainly---and this is his main point---theft of intellectual property is
     theft. However, property protected by U.S. intellectual property laws, notably
     copyright and patent protection (especially the latter)---can not simply be
     withheld from use at the whim of the owner. For example, patent holders MUST
     license equally to all who meet reasonable terms. Indeed, the _purpose_ of
     copyright and patent protection is to promote the widest possible access to
     the new ideas by insuring that their creators have economic motivation to do
     develop them. The owners of intellectual property who want to restrict its
     distribution are expected to look to the trade secret laws to protect them.
     
     I'm not sure what requirements are imposed on copyright holders (and as an
     aside, I sure would like The National Computer Security Assn. to argue that
     copyright, not patent, is the only appropriate form of protestation for
     software! heh, heh, heh.), but I suspect they can not capriciously and
     arbitrarily withhold copy permission from some but not others, and it will
     even surprise me if they can put irrelevant terms in the copy permission. None
     of this speaks to licensing, but (I speculate) the only legal culprit in a
     licensing violation is the licensee who allowed the copy. And presumably that
     contract violation is a civil, not a criminal matter in American law.
     
     Bob, not an attorney, Morris
     
     
---------------------------------------------

Don't always believe those E-Mail addresses

A. Padgett Peterson, Information Security <padgett@tccslr.dnet.mmc.com >
Wed, 11 May 94 08:17:46 -0400
     
     One of the more subtle RISKS of E-Mail is in believing what you see.  Recently
     a good friend of mine was repeatedly accused of posting not-so-nice messages
     on various news-groups. Not so blatant as to be unbelievable but morally
     damaging. This irritates me.
     
     A few months ago I was flamed in RISKS for talking about the use of Ethernet
     card firmware addresses as for tracking. Two weeks ago it enabled me to
     quickly and positively identify the source of repeated failed attempts to log
     into an Ethernet server as supervisor. When I asked the administrator for the
     data in the log, he told me that he had never known that the six hex bytes had
     a meaning.
     
     Similarly, forged E-Mail is possible only because many E-Mail packages throw
     away the Ethernet wrapper that made the communication possible in the first
     place, a wrapper that *must* contain the return address or "the mail won't go
     through".
     
     Here I have FTP Software's (plug) PCTCP which provides an MSDOS machine with
     more built-in features than many UNIX implementations (won't go into them all
     else it would be an adv't but will just say that it allows me to identify not
     only the source, but the path used to get here).
     
     For example what most people see in an E-Mail posting is this (lines have been
     wrapped to 80 characters & true returns masked) - Judge and Goat are two PCs
     in my office.
     
      -----------------------------------------------------------------
      From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34
      To: padgett@goat.ppp.qqq.rrr
      Return-Path: <Crusader_Rabbit@Jay.Ward.Cartoons>
     
      Demonstration of message headers.
      -----------------------------------------------------------------
     
     What was actually received from the SMTP server was this but most
     newsgroups & many mailers strip the "Received: from..." as above:
     
      -----------------------------------------------------------------
      From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34
      X-Envelope-To: padgett@goat.ppp.qqq.rrr
      Return-Path: <Crusader_Rabbit@Jay.Ward.Cartoons>
      Received: from judge.ppp.qqq.rrr ([123.456.789.000]) 
                by Goat.ppp.qqq.rrr (SMTPSRV); Wed 11 May 1994 07:34
     
      Demonstration of message headers.
      -----------------------------------------------------------------
     
     Note that not only the originating name is sent but also the true IP 
     address [123.456.789.000]. Again this *must* be there.
     
     Not to say that this is not a valuable capability since I prefer that
     all incoming E-Mail come to a common point, just don't rely on them
     since they can be *anything* the sender wishes.
     
     Don't just toss those wrappers, dispose of them properly.
     
     Padgett
     
     
---------------------------------------------

EFF's Kapor announces new cyberspace tv show

Stanton McCandlish <mech@eff.org>
Tue, 10 May 1994 20:47:23 -0400 (EDT)
     
     Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist
     
     Forwarded message:
     Date: Tue, 10 May 1994 09:13:23 -0400
     From: mkapor@kei.com (Mitchell Kapor)
     Subject: My tv show
     
     (I thought you might be interested in this.)
     
     New Cyberspace TV Program
     
     I am developing a new program on cyberspace in conjunction with WGBH-TV, PBS'
     Boston affiliate.  The show is intended to be a window onto the world of
     computer networks for the television viewer, whose point of view is that the
     world of on-line communications is interesting because of what people do
     there, not because of the digital plumbing which enables it.  We will be
     focusing on the human aspects of networking and the individual and social
     aspects of being on-line.  Cyberspace will be portrayed as a not-so-really
     strange territory after all, where all of us will increasingly come to live
     and work.  My role is to guide people through this new territory, introducing
     the audience to its native culture, its scenic attraction, and its sights and
     sounds.
     
     We assume our audience is motivated by curiosity to learn more about what goes
     on in cyberspace, but we do not assume they are knowledgeable or, in general
     experienced with it.  On the other hand, we will not trivialize the subject
     matter by reducing it to a least common denominator.
     
     We will give the show a look and feel which is approachable and down-to-earth.
     Interview guests and roundtable participants will be drawn from the net
     community itself.  There will be plenty of demos of cool net stuff from
     Mosaic, CU See Me, and other cutting-edge applications and services.
     
     We are taping two test shows in mid-June which will be shown in Boston and
     other cities and hope to have some sort of national distribution (to be
     determined) in the fall for a regularly scheduled program.  We are also going
     to create a WWW server for the show, the segments of which will be
     downloadable.  The server will be have on it additional material which won't
     fit into the show format.
     
     
     An Invitation:
     
     We would like to include some video clips of net citizens expressing their
     greatest hope and worst fear about the future of the net which we will edit
     into an on-air piece for our regular feedback session.
     
     It's important to me to have the voices heard (and faces seen) of people
     already on the net.  This is an opportunity for those of us who enjoy
     appreciate the decentralized and democratic character to express that
     sentiment to a mass audience.  I hope you'll take advantage of the
     opportunity.
     
     
     Guidelines:
     
     Since an individual on-air clip will run at most 20-30 seconds, please keep
     your statement succinct.
     
     In shooting the clip, please feel free to pick a location which says something
     about yourself, whether it's your computer, your pet, or the great outdoors.
     
     We can accept Quicktime movies, VHS cassettes, or 8mm tapes.  If you enclose a
     mailer, we will return your tape.  We can also pick up digital submissions
     from any FTP site, etc.
     
     
     Contact Information:
     
     email:  cybertv@kei.com
     
     Postal: CyberTV
     c/o Kapor Enterprises, Inc.
     238 Main St., Suite 400
     Cambridge MA 02142
     
     
---------------------------------------------

Automation: request for input

Ken Funk <funkk@ENGR.ORST.EDU >
Thu, 28 Apr 94 06:59:08 PDT
     
     Oregon State University, America West Airlines, and Honeywell are conducting a
     study of flightdeck automation for the Federal Aviation Administration which
     requires input from the scientific community.
     
     The increasing use of automation on the flightdecks of commercial transport
     aircraft has raised concerns about the overall safety effects of this
     equipment.  While several studies have attempted to address some of these
     automation issues, until now no one has tried to systematically identify all
     issues that exist about flightdeck automation.  The objectives of this study
     are to collect and compile a comprehensive list of all flightdeck automation
     problems and concerns and to address them in order to identify or generate
     recommendations and guidelines for the FAA, manufacturers, and operators.
     
     To achieve these objectives we are soliciting information on automation
     problems and concerns from individuals in a variety of disciplines.  When we
     have compiled these problems and concerns we will prioritize them, study the
     highest priority items using analytic methods and simulator studies, and
     identify and develop recommendations based on our findings.
     
     Although we are primarily targeting the aviation community for sources of
     automation problems and concerns, we recognize that individuals in other
     disciplines have knowledge of other kinds of system automation and know of
     automation problems or have concerns about automation that would be very
     relevant to our study.  Experts in computer science, human factors
     engineering, psychology, and other fields often deal with the automation of
     industrial systems, office equipment, and even consumer devices, so we welcome
     information from them.
     
     If you have direct knowledge about system automation and you know of problems
     with or have concerns about the safety of such automation, you can help us by
     filling out a copy of our Automation Problems and Concerns Questionnaire. This
     is an opportunity for you to contribute to flight safety and, if you wish, we
     will put you on our distribution list to receive copies of reports on the
     results of our study.
     
     If you would like to fill out a questionnaire, send a message to
     flight@engr.orst.edu (don't post your request to this newsgroup!).  Request a
     copy of the Automation Questionnaire, and I will send you a copy via e-mail.
     When you have completed it (which should take between 15 and 30 minutes), just
     e-mail the completed version back to me.  The problems and concerns you
     identify will be added to our database and used in our study.
     
     Ken Funk, Assistant Professor of Ind. and Mfg. Engineering, Oregon State Univ.
     flight@engr.orst.edu, funkk@engr.orst.edu  (503) 737-2357  FAX: (503) 737-5241
     
     
---------------------------------------------

Previous Issue Index Next Issue Info Searching Submit Article


Report problems with the web pages to Lindsay.Marshall@newcastle.ac.uk.
This page was copied from: http://catless.ncl.ac.uk/Risks/16.05.html
COPY!
COPY!
Last modification on 1999-06-15
by Michael Blume