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/18.67.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 18, Issue 67

Friday 13 December 1996

Contents

o Washington State Unemployment Checks "Delayed"
Richard Berry
o More on the complexity of software upgrades
Nancy Leveson
o .pdf files -- RISKS of using Adobe Acrobat Reader
William Ehrich
o Re: Combatting cookies
Bruce Schneier
o Re: Amtrak ticket system breaks down
Robert Perillo
o Re: Aviation Accident Rates
Mark Stalzer
o Re: Don't touch this switch!
Darin Johnson
o Re: A visit from the Goon Squad: computer evidence
Scott Gregory
o CEPIS Statement: Security at risk due to encryption restrictions
Kai Rannenberg
o The InterNIC: a case study in bad database management
Jonathan I. Kamens
o Abridged info on RISKS
comp.risks
---------------------------------------------

Computer malfunction causes panic selling at Hong Kong stock exchange

Joel Chan <joel@math.toronto.edu>
Fri, 13 Dec 1996 02:12:43 -0500
     
     A computer glitch in the Hong Kong Stock Exchange caused panic selling on 12
     Dec 1996 when its Teletext information system incorrectly reported a drop of
     515 points (or about 4%) of the Hang Seng Index during the opening minutes
     of trading.
     
     The error was blamed by a malfunction in the Automatic Order Matching and
     Execution System (AMS), which calculates up to the minute stock prices
     during trading hours.  The Stock Exchange had apparently alerted dealers
     that there was a problem with the computer before trading began and were
     advised to use prices shown in free text areas for calculating opening
     quotations.  However, the Teletext system made no indication of the computer
     glitch and instead displayed inaccurate stock prices until 20 minutes after
     trading began.  The stock exchange is reviewing the incident.
     
     Official figures for all indices and stock prices were finally released the
     evening after the exchange closed.  The Hang Seng index, Hong Kong's main
     stock index, ended the day down 136 points (1.0%) at 13053.28.  Volume was
     just over US$1 billion.  The loss was partly blamed by the computer glitch.
     
     
---------------------------------------------

Washington State Unemployment Checks "Delayed"

"Berry, Richard, Maj, AF/SCTA" <RBERRY@af.pentagon.mil>
Thu, 12 Dec 1996 14:20:03 -0500
     
     >From the KOMO (Radio/Television station) news web site, 12 Dec 96:
     
     "A state computer might be the Grinch that is stealing Christmas for some
     unemployed people. The computers cranked up two weeks ago to process claims
     for unemployment insurance have "mislaid" checks for up to two-thousand
     jobless people. The weekly checks are as much as 365 dollars
     each. Employment Security commissioner Gary Moore notes that tens of
     thousands of checks were properly sent out. He says the system works well,
     but has some bugs that need to be worked out. But Moore also acknowledged
     that people who haven't gotten their checks need the money, and waiting for
     checks from the state is unacceptable."
     
     
---------------------------------------------

More on the complexity of software upgrades (Re: Bauer, RISKS-18.65)

Nancy Leveson <leveson@cs.washington.edu>
Thu, 12 Dec 1996 18:19:54 PST
     
     As an "old-timer" in this field (and an IBM systems engineer -- customer
     rep), we knew better than to assume that new software or hardware would work
     correctly when first installed.  It would be considered negligence to
     install something without running in parallel with the old system or
     installing it at anything but a low-activity time.
     
     There are way too many untrained and ignorant people out there selling
     themselves as "consultants" or programmers.  I've even had high school
     students tell me that they were hired to write safety-critical software.  Is
     this their fault or the fault of people who think they can hire someone
     without training or proper credentials to do these jobs?  I have never
     understood what it is about computers that that makes people believe that
     anyone can be an instant expert.
     
     Nancy
     
     
---------------------------------------------

.pdf files -- RISKS of using Adobe Acrobat Reader

William Ehrich <ehrich@minn.net>
Fri, 13 Dec 1996 08:20:11 -0600
     
     A lot of the user manuals for Macintosh applications are now published using
     the .pdf format. They are expensive to print and hard to read on a monitor
     with less than 1800 x 2400 pixel resolution. So a lot of people don't read
     them.
     
     Are there increased risks of various kinds from making user instructions
     less accessible?
     
     - Bill Ehrich
     
     
---------------------------------------------

Re: Combatting cookies

Bruce Schneier <schneier@counterpane.com>
Fri, 13 Dec 1996 16:59:05 -0500
     
     For a while I would have my Netscape browser alert me every time a cookie
     was sent, so I could refuse it.  Some pages send three of more cookies upon
     loading, and this quickly became annoying.  Recently I set up a batch file
     that trashes my cookie file every time I boot my computer up.  Works great.
     
     Bruce Schneier  Counterpane Systems  schneier@counterpane.com   
     http://www.counterpane.com/  APPLIED CRYPTOGRAPHY 
     
     
---------------------------------------------

Re: Amtrak ticket system breaks down (RISKS-18.64)

<Perillo@DOCKMASTER.NCSC.MIL>
Thu, 12 Dec 96 16:01 EST
     
         As reported in the New York Times, "Failure of Ticket Computer
         Snarls Amtrak at Busy Time", Saturday 11/30/96, page 30.
         Amtrak's Central Computer did not go "belly up", but the
         communications/networking hardware that connects the ticketing
         agents around the country to the Central Computer failed.
     
         Starting about 12:30pm on friday, Thanksgiving weekend, Amtrak's
         reservation and ticketing system for the entire country broke
         down causing total chaos and long lines. As of late friday night
         the system was still not working, But no train delays were reported.
         Ticketing agents, dependent on the system and lacking
         printed tables of fares, in many cases guessed at fares and
         overcharged passengers.
     
         While more information is needed, it seems strange that no Risk
     Analysis was done prior to the breakdown to identify the piece of
     communications hardware as a possible single point failure (SPF)?
     Why wasn't a redundant communications link to the central computer
     available? This is standard Avoidance and Diversity (A&D)
     provisioning.
     
         Plus, a manual backup system should have been in place.  Ticketing
     agents should have had up-to-date printed tables of fares and forms, like
     the train conductors carry.
     
     Robert Perillo,     Perillo@dockmaster.ncsc.com
     
     
---------------------------------------------

Re: Aviation Accident Rates (Ladkin, RISKS-18.66)

Mark Stalzer <stalzer@macaw.hrl.hac.com>
Thu, 12 Dec 1996 13:16:10 -0800
     
     The trouble with the aviation accident statistics is that they only show
     that new airframe and engine designs with glass cockpits are safer than old
     airframe and engine designs with traditional controls. It could very well be
     the case that great improvements in the reliability of new airframes and
     engines are offsetting serious deficiencies in the modern controls. There is
     a risk that manufacturers will hide behind the statistics and resist efforts
     to determine the dangers and benefits of high levels of cockpit automation.
     
     Mark Stalzer, mas@acm.org
     
     
---------------------------------------------

Re: Don't touch this switch!

Darin Johnson <darin@connectnet1.connectnet.com>
12 Dec 1996 21:53:34 GMT
     
     Speaking of not touching switches, I used to have a computer at work that
     had an odd button design.  I don't want to say the name in public (Dell)
     though.
     
     The power switch was big and easy to see and stuck out from the case.  The
     reset switch was about the size of a pencil eraser, and flush with the case
     so that it could not be pushed with a finger.  I had to use a pen cap to
     push the reset.
     
     The only rational I could see is that they didn't want anyone pushing reset
     by accident, even though I managed to shut down power on it once by accident
     with my knee.  Yes, pushing reset is bad (except that it's the number one
     solution given when you tell people that Windows isn't working right), but
     pushing the power button is worse.  And that's exactly what's easiest to
     push, and if you stuck an average computer illiterate user in front of it,
     that's what they would push.  Even those who noticed the reset button might
     mistakenly assume that because of the deliberate design that it would be
     better to push power instead of reset (and maybe even start doing so on
     other systems with better button design).
     
     Darin Johnson  darin@connectnet.com
     
     
---------------------------------------------

Re: A visit from the Goon Squad: computer evidence

Scott Gregory <sgregory@inforamp.net>
Thu, 12 Dec 1996 20:00:51 -0500
     
     The RISKS?  
     
     As Nick put it, the police in many countries have a long way to go in their
     understanding of computer crimes, however, just imagine what would have
     happened if the police had acted 'appropriately'.  They would have impounded
     ALL servers in the building that Mr. X had a login to, or any that he might
     have been likely to have unauthorized access to.  They might have taken ALL
     laser printers in the building.  Or at least the one that was Mr. X's
     'default' so that they could examine it.  If Mr. X had access to other
     machines at the site, they would have taken those as well.
     
     The RISK is more complex than first thought.  The Jackson Games case in the
     U.S. was fought on similar grounds - what is fair seizure and what is not?
     
     I imagine that the "major computer company" might have had 'major'
     problems had the police actually 'done their job'.
     
     Scott Gregory - Mississauga, Canada.
     
     
---------------------------------------------

CEPIS Statement: security at risk due to encryption restrictions]

Kai Rannenberg <kara@telematik.iig.uni-freiburg.de>
Tue, 26 Nov 1996 00:28:31 +0200
     
     Council of European Professional Informatics Societies (CEPIS)
     POLICY STATEMENT, 1996-October-20
     
     Governmental Restrictions on Encryption Products Put Security at Risk
     
     Worldwide, there is a political debate regarding the virtue or otherwise of
     a control of encryption, in particular whether the import, export, and
     production of cryptographic tools and their use should be restricted. In
     several countries legal regulations exist, in some others steps are
     undertaken towards such regulations. At present an OECD Committee is
     drafting guidelines on cryptographic policy.
     
     But there are concerns; the Council of European Professional
     Informatics Societies (CEPIS) - with nearly 200,000 professionals in its 20
     member societies, the largest European association of professionals working
     in information technology (IT) - has agreed the following statement:
     
     Should one wish to employ electronic communication as the main vehicle for
     commercial and personal interaction, then one ought to be assured, and be
     able to prove, that  messages are
     - not disclosed to unauthorised recipients (confidentiality),
     - not tampered with (integrity),
     - shown to be from the senders stated (authenticity).
     
     It has always been an aim of secure reliable communication to comply with
     these requirements. The more the information society becomes a reality, the
     more enterprises, administrations and private persons urgently need the
     absolute assurance that these requirements are met.
     
     To achieve this, so called "strong" cryptography is available. Several tools
     based on strong crypto-algorithms are in the public domain and offered on
     the Internet, others are integrated within commercial products.
     
     A different technique for confidential and even unobservable communication
     is to use steganography, where secret data are hidden within larger
     inconspicuous everyday data in such a way that third parties are unable even
     to detect their existence. Hence there is no way of preventing unobservable
     secret communication.
     
     To enable surveillance of electronic messaging, many criminal and national
     security investigators, i.e. police and secret services, demand access to
     keys used for encrypted communication.  In order for this to be effective,
     escrowing (bonding) of these keys is advocated.  However, for the reasons
     given above, key escrow (i.e. depositing copies of the keys with a "trusted
     third party",including back ups) cannot even guarantee effective monitoring.
     Moreover, key escrow already constitutes a risk for the secrecy of the keys
     and therefore for the secrecy of the data. This risk is exacerbated in cases
     of central escrowing.
     
     Besides, the burdens of cost and administrative effort as well as the loss
     of trust in communications could be significant and are prone to deter
     individuals and organisations, especially small business users, from gaining
     the benefits of modern information and communications systems.
     
     Effective electronic surveillance of digital networks is difficult and time
     consuming, and requires extensive resources.  In particular, closed groups
     such as criminal organisations might even use steganographic techniques to
     avoid any detection short of physical access to the terminals they use.
     Thus restrictions on encryption may be of very limited help in the fight
     against organised crime.  On the other hand, the essential security of
     business and private communication may be seriously imperiled and
     economically hampered should they be subjected to insufficiently secured key
     escrow.
     
     On these grounds, CEPIS recommends the following:
     
     (1) The use of cryptography for identifying data corruption or
     authenticating people/organisations should be free of restrictions and
     encouraged by governments.
     
     (2) All individuals and organisations in the private and public sectors
     should be able to store and transmit data to others, with confidentiality
     protection appropriate for their requirements, and should have ready access
     to the technology to achieve this.
     
     (3) The opportunity for individuals or organisations in the private and
     public sectors to benefit from information systems should not be reduced by
     incommensurable measures considered necessary for the enforcement of law.
     
     (4) The governments of the world should agree on a policy relating to their
     access to other people's computerised data, while seeking the best technical
     advice available in the world on:
     
     (4.1) whether and which access mechanisms to computerised data are an
     effective, efficient and adequate way to fight (organised) crime and mount
     effective prosecution of criminals, and
     
     (4.2) how to implement the policy whilst minimising the security risks to
     organisations and individual citizens.
     
     (Evaluation and implementation of the policy will require regular review as
     the technology evolves).
     
     Further Information:
     
     Council of European Professional Informatics Societies (CEPIS)
     7 Mansfield Mews
     GB London W1M 9FJ
     United Kingdom
     
     Tel/fax: +44 171 637 5607
     E-mail: cepis@bcs.org.uk
     URL: http://www.bcs.org.uk/cepis.htm
     
     The CEPIS Legal & Security Issues Network
     URL: http://www.wi.leidenuniv.nl/~verrynst/cepislsi.html
     E-mail: Kai Rannenberg (kara@iig.uni-freiburg.de), Secretary
     
     
---------------------------------------------

The InterNIC: a case study in bad database management

"Jonathan I. Kamens" <jik@cam.ov.com>
Thu, 12 Dec 1996 17:07:04 -0500
     
     (This message was also sent to comp.protocols.dns.ops .)
     
     The InterNIC (http://www.internic.net) is responsible for Internet domain
     name service for all top-level domains, as well as for second-level domains
     underneath all the old ARPA domains except MIL (EDU, GOV, NET, ORG, COM).
     Until a few years ago, domain registration services were provided by the
     InterNIC for free.  That changed when they convinced the NSF that its grant
     money wasn't enough to cover their costs, so (amid much hubbub on the Net)
     they started charging $50 per year for any second-level domain registration,
     with the first two years (i.e., $100) payable in advance.
     
     According to <http://rs.internic.net/nic-support/nicnews/stats.html>, the
     InterNIC registered 638,788 new domains between August 1993 and September
     1996.  If I'm doing my math right, at $100 per domain, that's almost $64
     million, or over $20 million per year.  I would think that with that much
     money, they'd be able to provide competent service to their customers.
     Unfortunately, my experience has been that they're simply not doing an
     acceptable job.  Some examples:
     
     *****
     
     * Their automated systems do not function properly.
     
       They've introduced a PGP-based system for authentication of domain
     contacts.  In other words, they allow domain contacts to register
     their PGP public keys in the InterNIC public-key database, and then
     requests which come from those contacts will only be accepted as
     authentic if they are signed with the corresponding provide key.
     
       Unfortunately, this system does not always work.  Recently, I
     submitted a series of twelve database modification requests to the
     InterNIC in a single day.  All of them were correctly signed with my
     PGP key.  Of the twelve requests, three were returned to me in
     messages beginning, "We are not able to verify the PGP signed message
     that you sent us."
     
       To make matters worse, for one of those three failed requests, I received
     a message claiming the the modifications I'd requested had been completed,
     two days *before* I received the message informing me that they were unable
     to verify my PGP signature.
     
       I have asked the InterNIC multiple times why their system randomly fails
     to verify valid PGP signatures.  They have not responded to my inquiries.
     
       Interestingly enough, another poster to comp.protocols.dns.ops claimed
     that when he asked an InterNIC on the telephone about their PGP
     authentication system, he was told that it is not currently working.  That
     would seem to indicate that the InterNIC is aware that there are problems
     with it, and yet they continue to advertise it on their Web site without any
     indication that it might not work for any given request.
     
     * There are some data in the database which are impossible to update using
     the templates they provide.
     
       One of the types of data stored in the InterNIC database is hosts; in
     particular, hosts which act as domain-name servers for domains registered
     with the InterNIC have records in the database.
     
       Host records include an organization name and address associated with the
     host.  And yet, the template for updating host records (available at
     <ftp://rs.internic.net/templates/host-template.txt>) does not have fields in
     it for updating that information!  I believe that there are a couple of
     other record types in the database which have this same problem.
     
       This organization/address data has been described to me by an InterNIC
     employee as an "old hold-over;" it seems that new host records do not have
     organization and address data, but old ones do.  Nevertheless, one would
     think that when switching to a new format for host records, the InterNIC
     would have either removed the obsolete data from the old records or
     established a procedure for updating it.
     
       Instead, the only way to update this information electronically is to send
     a plain-text message to hostmaster@internic.net explaining what you're
     trying to do, and then hope that whoever reads your message will be
     competent enough to understand what you're asking for and do the update by
     hand.  Which brings me to my next point...
     
     * When asked how to do something that is not handled automatically by their
     templates, their staff give incorrect answers (or simply ignore the query)
     more often than they give correct answers.
     
       Of the twelve requests mentioned above, six of them were handled
     improperly by the InterNIC staff members who processed them.  Iwn several
     cases, I received a response instructing me to use a particular template to
     make the changes I had requested, when in fact those changes had nothing
     whatsoever to do with the template they told me to use.
     
       I finally had to escalate my requests by sending "out-of-band" E-mail to
     an InterNIC employee who has resolved problems of this sort for me in the
     past, and she was able to "bounce" my requests to a high enough level that
     they actually got processed.
     
       Incidentally, the InterNIC introduced one or more typographical errors
     into the data I sent them when processing six of my twelve requests (i.e.,
     when they were done processing my requests, six of the twelve records I
     asked them to modify had one or more typographical errors in them).
     
       I suppose that sending incorrect answers is better than how things were a
     few months ago -- then, if you sent a request that the person who read your
     message did not know how to answer, he/she simply ignored it and sent no
     response whatsoever.
     
     * There are some data in their database which are impossible to update using
     their current procedures.
     
       Imagine this scenario... Joe Admin at Foo, Inc. is responsible for system
     administration, including DNS administration.  He therefore has a contact
     record in the InterNIC database indicating that he works for Foo, Inc., and
     he is listed as a contact for various domain, network, and host records, in
     the InterNIC database.
     
       Now, he leaves the company and takes a new job, with no further contact
     with Foo, Inc.  He doesn't bother to update his contact record in the
     InterNIC database before he leaves.
     
       Foo, Inc. would rather not let records remain in the InterNIC database
     claiming that Joe works for them when in fact he does not.  Therefore, they
     want to contact the InterNIC and tell them, "Look, the information in Joe
     Admin's contact record which says that he for us is incorrect.  You can
     confirm this by attempting to send E-mail to the address in the record, or
     by calling the phone number in the record and asking to speak to him.  The
     person who answers will confirm that he no longer works there.  Please
     either delete the contact record completely or remove the information in it
     which associates Joe Admin with Foo, Inc."
     
       Sounds reasonable, right?  Well, unfortunately, the InterNIC has *no
     procedures whatsoever* for allowing a company to remove contact information
     which incorrectly lists them.
     
       I attempted to do just what I described, i.e., to get the InterNIC to
     remove the contact record for a former employee of OpenVision who no longer
     works here, and who I cannot contact to ask him to update his own record
     (and considering that it's not hurting him in any way, I don't see that he'd
     have any incentive to update it even if I could ask him to).
     
       After several rounds of E-mail with the InterNIC, they called me on the
     telephone to discuss what I was trying to do.  Once on the phone with them,
     I was "bounced up" through several layers of InterNIC staff, until I was
     finally able to speak to a woman who was perfectly willing to admit that
     yes, the scenario I described was a somewhat common one, and yes, it was
     perfectly reasonable for a company not to want the InterNIC database to
     associate non-employees with the company, but no, there's no way for anyone
     but the owner of a contact handle to update it.  "Perhaps we need to
     establish a procedure for that, and I'll be glad to discuss that for you
     with our customer service manager, but we don't have one right now," she
     said, and she did not offer to make an exception and handle my particular
     request manually without the blessing of a "procedure".
     
       Presumably, this means that I could edit my own contact handle to
     indicate that I work for any company that I want, and that company
     would have no way to get the InterNIC to remove the fraudulent
     information.
     
       Similarly, presumably, that means that (to be a little morbid for a
     moment), if someone listed in the InterNIC database dies, there's no way for
     anyone else to get the InterNIC to remove the deceased's record from the
     database.
     
       When I pressed the woman about this, she said to me, "If you're a network
     administrator at this company, you presumably have control over the mail
     server" (an assumption which is not always true, and indeed isn't true in
     this case; although I can ask the people who administer the mail server to
     make changes and hope that they'll listen, I don't have the ability to make
     the changes directly).  "Well," she continued," if you send us a mail
     message which claims to be from the former employee, asking for his record
     to be deleted, we'll process it."
     
       "Let me get this straight," I responded.  "You're telling me that I should
     forge E-mail to your system in order to delete this record."  She confirmed
     that interpretation.  I said, "Surely you see the absurdity of that."
     
       She responded, "Well, obviously, ideally we wouldn't want anyone forging
     requests to our system, but in this case, that's the only way for you to
     delete the record."
     
       "What if the former employee had associated a PGP key with his contact
     record before he left the company."
     
       "Well, in that case, you'd need his private PGP key in order to delete the
     record."
     
       "But surely you know that's impossible -- the whole point of PGP is that
     only the owner a private key has access to it.  Even if I had access to the
     file in which it was stored, I wouldn't know the correct password to unlock
     it."
     
       "Well, in that case, there would be no way for you to delete the record."
     
     *****
     
     There are a number of countries with strict laws about the collection of
     private information in computerized databases.  Database maintainers are
     required to seek permission from all individuals who have data about them
     stored in the database, to guarantee the security of the database, and to
     establish working procedures for keeping the data in the databases
     up-to-date.
     
     The United States has few such laws (there are laws about specific types of
     databases, such as credit and medical records, but no laws about databases
     in general).  Until I started dealing with the InterNIC, I didn't see much
     point to them.  Well, I've changed my mind.  the InterNIC proves rather
     clearly that left to their own devices, companies will not maintain
     databases in a responsible manner.
     
     Incidentally, nowhere on the InterNIC's WWW site can I find the address or
     telephone number of the governmental office which oversees their grant and
     handles complaints about their services.  Several months ago, I sent them
     E-mail asking for them so that I could file a complaint, to be considered
     the next time their grant comes up for renewal.  Like many of my other
     messages to them, that request was ignored.
     
     Jonathan Kamens  |  OpenVision Technologies, Inc.  |   jik@cam.ov.com
     
     
---------------------------------------------

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/18.67.html
COPY!
COPY!
Last modification on 1999-06-15
by Michael Blume