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 19 Issue 57

Monday 26 January 1998

Contents

o Air Force thinks push-pull technology too risky
Edupage
o Risks of Transit Automation
Dave Pierson
o OSS Risks, Bell Atlantic forgets AT&T charges in phone bill
Robert J. Perillo
o robots.txt: ``Here is what I am not telling you.''
Bertrand Meyer
o Each step makes sense, but the result is broken
Cliff Sojourner
o Y2K correction at IRS threatens 1,000 taxpayers
Mich Kabay
o Y2K bug may lead to lawsuits
John Mainwaring
o Y2K affects miniature enthusiasts
Lee Ann Rucker
o Risks of making assumptions on education
Joe Thompson
o Possible Netscape source code risks
John Wilson
o Filing for divorce on the Internet
Steven M. Bellovin
o Re: CyberSitter to the rescue
Nick Brown
Leonard Erickson
o GPS position accuracy and EGPWS
Ron Crandall
o CERT Advisory CA-98.02: Vulnerabilities in CDE
CERT
o Re: Software Engineering Code of Ethics
Don Gotterbarn
o Info on RISKS (comp.risks)

Air Force thinks push-pull technology too risky

Edupage Editors <educom@educom.unc.edu>
Sun, 25 Jan 1998 14:37:28 -0500
The U.S. Air Force is in the process of evaluating whether to use or ban
numerous products from PointCast, Netscape, Microsoft, and BackWeb that use
"push-pull" technology to manage information transfer between server and
client computers.  In October an Air Force memo declared: "Effective
immediately, all commercially available auto push-pull data gathering
applications ... are to be disabled from all networks.  Currently, these
technologies introduce security risks and impact data throughput on our
networks than cannot be tolerated."  The companies involved insist their
software is secure.  (News.Com 23 Jan 1998; Edupage, 25 Jan 1998)


Risks of Transit Automation

<pierson@gone.ENET.dec.com>
Sat, 24 Jan 98 17:17:29 EST
It was mentioned that the Vancouver Skytrain system startup was delayed,
during a recent snowstorm, awaiting the arrival of 'on board crew'.  Because
the system is completely automated, this was proposed to be a questionable
tradeoff, forcing people onto the snowy streets.

Mayhaps.  It was, however, just about one year ago that the Washington DC,
US Metro system had its first fatality.  A driver was killed when the train
(empty) failed to stop in a stabling siding, during a snowstorm.  The
relevant point is that the DC Metro, too, is essentially automated.  All the
driver does is open & close doors, normally.  This particular driver had
been requesting permission to drive manually, since the set had been
overshooting stops, especially on the surface.  He was repeatedly denied
permission, by the humans in central control.  He died, due to sensor
malfunction and insufficient common sense in central.

I don't know if the crew on the Skytrain can drive, but they can at least
report malfunctions and hope someone listens....

Dave Pierson


OSS Risks, Bell Atlantic forgets AT&T charges in phone bill

<Perillo@DOCKMASTER.NCSC.MIL>
Fri, 23 Jan 98 22:36 EST
19 Jan 1998.  Bell Atlantic Corp. failed to bill approximately 400,000 AT&T
customers in parts of Virginia, Maryland, Washington D.C., and West Virginia
for their long-distance calls on their latest telephone bill.  AT&T stated
that their Operations Support Systems (OSS) provided Bell Atlantic with the
correct billing data for the three of the twenty billing cycles, customer's
billed on the 2cd, 4-5th, and 7th of the month, and that a Bell Atlantic
computer error failed to produce the AT&T portion of the bill.  Bell
Atlantic has stated that the problem was a "systems glitch", "processing
error", and/or "data processing error". The rest of Bell Atlantic's 26
million customers, outside the mid-Atlantic region, on a different billing
cycle, or not using AT&T as a long-distance provider, were not affected.

Bell Atlantic will include the omitted AT&T long distance calls in affected
customer's February phone bills. Special arrangements, including payment
extensions, will be made for any customer's who have problems budgeting next
month's bill.  It is assumed that AT&T which has a Billing and Collections
contract with Bell Atlantic, will receive refunds and penalty payments
because of the error?

This information comes from an AT&T press release, dated 16-Jan-1998,
reprinted in most local papers, such as the *Richmond Times-Dispatch*, 17
Jan 1998, page C10.  Bell Atlantic Customer Service Representatives seem to
know very little about the problem? Bell Atlantic has not reported the
details of the problem to the National Telecommunications Clearinghouse
dealing with Computer Reliability and Security, which they are supposed to
do, so that these type of technical problems can be corrected and prevented
by the industry in the future?

Supposedly, computer tapes were used to transfer the billing details between
AT&T and Bell Atlantic. Why is 1960's technology being used? Why aren't the
billing details transmitted electronically over a communications/computer
network between the two companies in Electronic Message Interexchange (EMI)
format using a Customer Billing Services System (CBSS)?

Operations Support Systems (OSS), which controls ordering, service
provisioning, administration, billing and collections, for
telecommunications services are becoming more complicated and critical in
this age of telecommunications de-regulation.  Risks of Slamming
(unauthorized change of service provider), Cramming (unexplained, unclear,
or invalid charges on the bill), Fraud, and billing inaccuracies (10-23%)
are directly controlled by the OSS. OSS software and equipment must have a
standardized interface, reliability, and security.

Robert J. Perillo, CCP  Richmond, VA   Perillo@dockmaster.ncsc.mil
[Disclaimers omitted; covered by the default disclaimers in risks.info]


robots.txt: ``Here is what I am not telling you.''

Bertrand Meyer <bertrand@eiffel.com>
Sun, 25 Jan 98 15:04:03 PST
Imagine the head of a large corporation who tells a TV interviewer: "Here is
the list of topics that I don't want anyone to know we are discussing with
potential business partners: ...". Or, for that matter, a President who
tells us "these are the young women I would hate you to know I had dealings
with in the past few years: ...". Pretty dumb, wouldn't it be?

Now look at the "Robot Exclusion Standard" (I think that's how it's called)
for Web sites. The need is clear: you may want to exclude some of the pages
on your Web site from consideration by the indexing "robots" -- Yahoo,
AltaVista and the like.  The solution is, how should I say, interesting: you
put at the top level of your site a file conventionally called `robots.txt',
which lists the directories that should not be indexed; well-behaved robots
will check it, and dutifully oblige.

Now whoever thought up that scheme must have been very smart, but the
smartness somehow eludes me. The file must obviously be world-readable, so
anyone can go to the top level of a site and look up `robots.txt' with a
plain browser. This is a good way to find out what the site owner doesn't
want you to know about. You don't see what's in the secret directories, of
course (well, assuming the Webmaster has done his job and made them
non-world-readable) [*], but you see what the secret directories are, and
just that can be quite valuable information.

The `robots.txt' scheme as it exists is acceptable if you simply want to
avoid having some of your Web information indexed by the search engines, for
example because it is in draft form or of time-limited value. But it is not
appropriate if your goal is to put on your Web site some secret information
that is only meant for some trusted partners. Yet there is a serious
possibility that unsuspecting companies will misuse the scheme for the
second of these applications.

This is not merely a hypothetical possibility. Just for fun I looked up
`robots.txt' for the Web sites of four or five well-known IT companies;
although regrettably I didn't find out any major scoop, I could see quite
clearly some of the topics those companies do not want others to know they
are working on.

The whole matter is very surprising, as the risk seems rather obvious and it
is not hard to think of alternative techniques that would have avoided it.

Bertrand Meyer, Interactive Software Engineering Inc., makers of ISE Eiffel
<Bertrand.Meyer@eiffel.com>, http://www.eiffel.com

  [* ... at least not without exploiting various security flaws.  PGN]


Each step makes sense, but the result is broken

Cliff Sojourner <cliff.sojourner@cisco.com>
Wed, 21 Jan 1998 15:41:13 -0800
Recently I lost a couple days worth of work updating some documentation.
(I'm working on a PC, running NT 4.0)  Here's how:

- I needed to update some documentation, so using the web-based document
control system I checked out the latest copy of the document.

- Netscape 3.01 puts downloaded files that require external viewers in
c:\temp, just as it was told to do.

- Netscape starts Adobe FrameMaker for me, to edit the document.

- I work on the document for two days (no, not continuously!),
diligently saving my work every few minutes.

- I quit FrameMaker, then I quit Netscape.

- Netscape cleans up the files it knows about in c:\temp.  Thanks a
bunch!  No, Netscape doesn't put the cleaned up files in NT's
Recycle-Bin.  No, the DOS undelete.exe program can't find the files in
the directory, either.

As I indicated in the subject, this is a minor example of a common
technology risk: each of the steps in the process makes sense independently,
but taken together the result does not make sense.

It makes sense for Netscape to put files in certain, user-configured
places.  It makes sense for Netscape to clean up temporary files when
it's done with them.  It makes sense for an application to save to the
file it has open.  It makes (debatable) sense for NT to not put
temporary files in the recycle bin when deleting them.

It does not make sense for my computer to delete a document I worked on.
On the other hand, how would it know?

Cliff Sojourner cls@cisco.com   http://www.employees.org:80/~cls/


Y2K correction at IRS threatens 1,000 taxpayers

"Mich Kabay [ICSA]" <Mich_Kabay@compuserve.com>
Mon, 26 Jan 1998 09:01:53 -0500
>From the Associated Press newswire via CompuServe's Executive News Service

IRS-Year 2000 (AP US & World, 23 Jan 1998)
By Rob Wells, AP Tax Writer, from Washington

The IRS uncovered an unintended side effect of its effort to eliminate the
Year 2000 computer bug: About 1,000 taxpayers who were current in their tax
installment agreements were suddenly declared in default due to a
programming error.

Rob Wells makes the following key points:

* IRS found and corrected the bug.
* There are 62 million lines of source code to check.
* The error was caused by an attempted Y2K fix.

M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education, International
Computer Security Association (Carlisle, PA) <http://www.icsa.net>


Y2K bug may lead to lawsuits

"John Mainwaring" <crm312a@nortel.ca>
26 Jan 1998 16:56 EST
Mike Easley, the Attorney General of North Carolina, was quoted in today's
Raleigh News & Observer via Associated Press as saying that state officials
are considering suing the computer industry to recoup the costs of making
sure government computers will work in 2000.

Comparing the situation with lawsuits against the tobacco industry, Easley
said, "The question ... is who knew what when."  The issue is whether
computer companies sold massive, multimillion-dollar systems that they knew
were destined to fail.

It certainly gives rise to an interesting vision:  all the programmers who
could be fixing the problem tied up testifying in lawsuits.

John Mainwaring  Nortel RTP NC  crm312a@nortel.ca


Y2K affects miniature enthusiasts

Lee Ann Rucker <lrucker@aruba.apple.com>
Fri, 23 Jan 98 14:36:31 -0800
  [This was posted to rec.arts.dollhouses.  NAME is the National Association
  of Miniature Enthusiasts.
    Lee Ann, working at Apple for Javasoft  lrucker@aruba.apple.com]

This is an alert to all NAME members.  If it doesn't affect you personally
please spread the word to others.  A member of N-2 recently called the
office to find out why she hasn't received her Houseparty Gazette.  She
discovered that, according to Kim, the computer has deactivated ALL members
whose memberships expire in the year 2000 and beyond.  Kim also said she had
no way of knowing who those folks are unless they call her and let her know.
So, if you know anyone who hasn't received their Gazette or any regional
mailings that might have happened (in N-2 the newsletter wasn't received in
Dec) have them call the NAME office immediately and talk to Kim.  This is
especially important since registration for the National Houseparty opens on
Feb. 2.

Carol <http://members.aol.com/spminis/spminis.htm>

  [I wonder if hyperactive miniature poodles can belong to NAME?
  They are certainly miniature and they are also enthusiastic.  PGN]


Risks of making assumptions on education (Wolper, RISKS-19.56)

Joe Thompson <abuse@orion-com.com>
Sun, 25 Jan 1998 11:56:31 -0500
RISKS-19.56 contains the following statement by Jim Wolper, in reference to
risks of misuse of the Enhanced Ground Proximity Warning System:

> After all, pilots are no more computer literate than the population at
> large.  I teach Computer Science at the university and flying at the
> airport, and there is no overlap between these student populations.

The assumption that appears to be made here is that computer science
students are more literate than the population at large.  There has been a
long discussion of this (widespread) assumption on alt.sysadmin.recovery
and the conclusion was that it is a rare CS program indeed which imparts
computer literacy to its students.

General agreement was that a CS degree certifies that you were given
certain tools and did certain things with them; whether or not you can do
different things with those tools, or use other tools, cannot be predicted.

The more disturbing assumption that might be inferred from the quoted text
is that the "general population" is uniformly *less* computer literate than
those with CS degrees.  This is most emphatically *not* true.

None of this is intended as a critique of Mr. Wolper or his teaching.  He
seems to be well-informed and I'm sure he does his level best to ensure that
his students (in both classes) are as well.  The risk here is that many
personnel departments do in fact hire on the basis of the above assumptions,
with no idea of what they're getting themselves into.

Joe Thompson, Charlottesville, VA   http://driver-8.rlc.net/


Possible Netscape source code risks

John Wilson <jowilson@mtu.edu>
Thu, 22 Jan 1998 21:43:24 -0500
As many of you already know, Netscape is releasing the source code to
Communicator 5.0 by the end Q1 1998.  I wonder how many Trojan horses will
have to be dealt with then.  "Oh, look, the latest version of Netscape
... click here."  Possibilities include tracking software built in the
browser, routines to copy personal information, including credit card
numbers, as well as the more "mundane" risks of simple file deletion/disk
wiping.

Netscape plans to make new versions out of developer improvements as well --
which leads to the possibility of disgruntled developers slipping in nasty
things into so-called bugfixes.

--John Wilson -- jowilson@mtu.edu


Filing for divorce on the Internet

"Steven M. Bellovin" <smb@research.att.com>
Fri, 23 Jan 1998 16:31:44 -0500
Israel To Offer Divorce by Internet
The Associated Press, 23 Jan 1998

There may be 50 ways to leave your lover, but the simplest way to file for
divorce will soon be as easy as clicking the right button on your computer.
Israelis will be able to seek divorce via the Internet, the daily Yediot
Ahranot reported Friday.  In the rabbinical courts, which have a monopoly on
granting divorces in Israel, the final preparations are being made to fuse
Jewish law and technology.  The new click-on method will save Israelis some
anguish. For many, seeking divorce has meant waiting for hours in crowded
smoke-filled halls without a guarantee of success on the first try.


Re: CyberSitter to the rescue (Johnson, RISKS-19.56)

BROWN Nick <Nick.BROWN@coe.fr>
Fri, 23 Jan 1998 10:26:03 +0100
A colleague of mine once worked on a project which involved modem firmware
for shipment to a U.S. customer.  One of the customer's requirements was the
the modem should filter out obscenity, and the developers were provided with
a list of "magic" words which were to be eliminated from the data stream.

The developers attempted to point out the folly of filtering binary data,
but they were overruled.  Purchasers of modems will be reassured to know
that the project was eventually cancelled for other reasons.  It is not
clear if the CEO of the customer organisation knew the difference between
his laptop computer and an Etch-a-Sketch (cf Dilbert).

I'm not a mathematician, but on the back of an envelope I reckon that
randomly-distributed MIME base-64 data should throw up any given four-letter
word, case-insensitive, about once a megabyte, give or take the line feeds.

Nick Brown, Strasbourg, France.


Re: CyberSitter to the rescue (Johnson, RISKS-19.56)

Leonard Erickson <shadow@krypton.rain.com>
Sat, 24 Jan 1998 11:41:18 PST
> ... So it blanks out "nu */ #de" without blanking out the
> punctuation and line breaks. ...

Alas, it's *necessary*, at least the "ignore non-alpha chars" part.
They have to be able to catch things like *N*U*D*E* *G*I*R*L*S*

Leonard Erickson (aka Shadow)  shadow@krypton.rain.com

  [Several readers reported that my parenthetical pun was censored. PGN]


GPS position accuracy and EGPWS

Ron Crandall <xrc@isi.com>
Mon, 26 Jan 1998 13:39:00 -0800
The recent note on EGPWS prompted me to write this note.  I don't remember
having seen a discussion in RISKS about the GPS reference datum problem that
can be a significant hazard.

In short, the GPS system uses a model of the Earths shape (an ellipsoid)
that is suitable for the entire Earth.  Almost all printed maps, and quite
likely many of the electronic maps derived from them, use an assortment of
ellipsoids that were typically optimized for a country or region.  The GPS
position when plotted on one of these maps can be off by a considerable
amount, as much as seven miles in some Pacific areas.  The half mile
discrepancy in the Caribbean has already led to several boat wrecks when
they tried to navigate a narrow passage in poor visibility using GPS data.

Considerable detail is available in yachting publications (e.g., the current
Ocean Navigator magazine), but the EGPWS article shows a way in which
aviators might be using unsurveyed approaches that would be subject to this
risk.

Ron


CERT Advisory CA-98.02 - Vulnerabilities in CDE (Excerpted for RISKS)

CERT Advisory <cert-advisory@cert.org>
Wed, 21 Jan 1998 17:09:16 -0500
CERT* Advisory CA-98.02, Original issue date: Jan. 21, 1998, Last revised: --

Topic: Vulnerabilities in CDE

The CERT Coordination Center has received reports of several vulnerabilities
in some implementations of the Common Desktop Environment (CDE). The root
cause of these vulnerabilities is that the dtappgather program does not
adequately check all information passed to it by users. As a result, it is
possible for a local user to gain unauthorized privileged access or cause a
denial of service on the system.

We recommend installing a vendor patch as soon as possible. Until you can do
so, we encourage you to disable vulnerable copies of the program. Section
III.A. of this advisory contains information on checking for potentially
vulnerable copies and disabling them. Section III.B and the appendix contain
vendor information.

We will update this advisory as we receive additional information.  Please
check our advisory files regularly for updates that relate to your site.

Fax      +1 412-268-6989

Postal address
         CERT Coordination Center
         Software Engineering Institute
         Carnegie Mellon University
         Pittsburgh PA 15213-3890
         USA

Getting security information
   CERT publications and other security information are available from
        http://www.cert.org/
        ftp://ftp.cert.org/pub/

   CERT advisories and bulletins are also posted on the USENET newsgroup
        comp.security.announce

   To be added to our mailing list for advisories and bulletins, send
   e-mail to
        cert-advisory-request@cert.org
   In the subject line, type
    SUBSCRIBE  your-e-mail-address

Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to cert@cert.org with
"copyright" in the subject line.

*CERT is registered in the U.S. Patent and Trademark Office.

This file in its entirety: ftp://ftp.cert.org/pub/cert_advisories/CA-98.02.CDE
See  http://www.cert.org/pub/alerts.html


Re: Software Engineering Code of Ethics

Don Gotterbarn <gotterba@Access.ETSU.Edu>
Mon, 19 Jan 1998 18:55:46 -0500 (EST)
Putting the Best Face on it--the real crisis.

An eighteen-year-old with no computer training declares herself to be an
experienced software engineer.  Many large expensive software projects are
never implemented or implemented in way that cause significant errors.

This state of affairs has been characterized by the cosmetic phrase
"Software Crisis".  This phrase is cosmetic in the same way as describing a
programming mistake I am responsible for as a "bug" is cosmetic.  Bugs just
seem to crawl into software-I am not responsible.  The "software crisis" is
a state of affairs that just is.  If we remove the cosmetics from the phase
"software crisis" we reveal the truth which might better be described as the
"software engineering crisis".  This crisis is best characterized by a
satisfaction with a Capability Maturity Model level 1 approach to software
development and the assertion that Software Engineering is still an immature
discipline with no standards.  Life is easy when there are no expectations
and standards.  Fortunately, software professionals are no longer willing to
use this make-up.  Software Engineering has a significant impact on society
and ought to adopt professional standards.

The IEEE Computer Society and the ACM established a Joint Steering Committee
for the Establishment of Software Engineering as a profession.  One task
force they established, the task force on Software Engineering Ethics and
Professional Practices (SEEPP), was to document the ethical and professional
responsibilities and obligations of software engineers.  The task Force
membership was international, spanning 15 time zones, with representation
from industry, the military, academe, and the legal profession/ The Task
Force has developed a Code for a sub-specialization within the
constituencies of both organizations and for the profession itself.

But the Code is much more than that.  The goal of the IEEE-CS/ACM Steering
Committee was to Professionalize Software Engineering.  Software engineering
as a discipline has particular idiosyncratic needs, as described in the
details of the Code.  The success of this effort to articulate the
professional responsibilities of software engineers has already been
recognized. The Texas Board of Professional Engineer's Licensing Committee,
in a recent meeting that addressed the subject of professional registration
of software engineers, recognized software engineering as a new discipline
with its own foundations and unique body of knowledge.  They also expressed
high regard for the Code of Ethics and Professional Practice.  Specificity
of practice is the key to the elaborated Code.

The discussion by the Texas Board of Professional Engineer's Licensing
Committee is but one example of significant discussions outside of the
professional societies about the status of Software Engineering.  The
attempt to address concerns about the quality of software products and the
talent of the software engineer on a local, regional, or national basis is a
mistake. The professionalization of software engineering requires a Code
that is international and that can be adopted by professional organizations,
industry, and individual professionals.  The Software Engineering Code of
Ethics and Professional Practice straddles the ACM/IEEE-CS gulf, and differs
enough from both the ACM and IEEE's more general codes to attract attention
from non-organizational types (like industries).  >From the evidence, the
Code seems to have accomplished both of these goals.  The Code has received
support from numerous countries including Australia, Canada, Czechoslovakia,
Egypt, Germany, India, Ireland, Netherlands, United Kingdom, United States,
and Uruguay. Most items of the Code surveyed had better than 95%
support. This indicates that the Code enjoys an international consensus.  It
also has received support from numerous industries, from large
multinationals to small software development firms.  The Software
Engineering Crisis is in pact due to a failure to stand up for professional
practices and accept responsibility for our work.  The Code can function as
an ethical charter for the profession. Such a Code can be used to aid in
decision making and as a means to educate the public, managers, trainees and
practicing professionals about professional standards and professional
responsibility.  The joint support of this development effort by the ACM and
the IEEE-CS shows the public that different organizations within the same
industry can cooperate, and makes it easier for professionals to understand
what their obligations are.  The general acceptance of the Code also
provides an explicit standard of good software practices against which
current practices can be measured.

The Code (www-cs.etsu.edu/seeri/secode.htm,
www.computer.org/tab/seprof/code.htm, and www.acm.org/serving) has been
forwarded to the leadership of the ACM and the IEEE-CS.
For further information contact Don Gotterbarn at gotterba@etsu.edu .
Computer and Information Sciences, East Tennessee State University
Box 70711, Johnson City, TN  37614-0711   1-423-439-6849

Please report problems with the web pages to the maintainer

Top