[comp.risks] RISKS DIGEST 11.52

risks@csl.sri.com (RISKS Forum) (04/24/91)

RISKS-LIST: RISKS-FORUM Digest  Tuesday 24 April 1991  Volume 11 : Issue 52

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

  Contents:
Another commuter train wreck in London (Clarinet via J.I. Kamens)   [YACTWiL!]
No beepers under 21 (Max Tardiveau)                                   [sic!]
Monitoring in the workplace (Jerry Leichter)
University Exec Backs Hacking (Dutch crackers) (anonymous)
Hacking a la Neerlandaise (Herman J. Woltring)
Responsibilities of Internet sites (was Dutch crackers) (Fernando Pereira)
Re: Dutch crackers and irresponsible officials (Steve Bellovin, Castor Fu)
Re: Dutch hackers and KSC (Bruce Oneel)
CERT Warning on Spoofs (Bill Murray)
Broadcast telephone calls (Iain Douglas)
Parity and SCSI (Tim Smith)

 The RISKS Forum is moderated.  Contributions should be relevant, sound, in 
 good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
 welcome.  CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive 
 "Subject:" line.  Others ignored!  REQUESTS to RISKS-Request@CSL.SRI.COM.  For
 vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
 CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 11, j always TWO digits).  Vol i
 summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
 <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
 If you cannot access "CRVAX.SRI.COM", try Internet address "128.18.10.1".
 ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
 Relevant contributions may appear in the RISKS section of regular issues
 of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Tue, 23 Apr 91 16:59:42 -0400
From: Jonathan I. Kamens <jik@pit-manager.MIT.EDU>
Subject: Another commuter train wreck in London

(Posted with permission from the ClariNet electronic newspaper service & UPI.
People who want more info on ClariNet can mail to info@clarinet.com or phone
800-USE-NETS.)

Date: 22 Apr 1991 08:46:20 GMT
From: clarinews@clarinet.com
Subject: Computer-controlled commuter trains collide in east London
Newsgroups: clari.news.trouble,clari.news.europe
Message-ID: <Ubritain-railway_265@clarinet.com>

        LONDON (UPI) -- Two computer-controlled commuter trains collided at the
height of morning rush hour in London's Docklands district, shutting down the
railway system and forcing the evacuation of dozens of passengers, police and
witnesses said.
        One two-car shuttle traveling through the Isle of Dogs from London's
Tower Gateway was struck by a second-two car train approaching from the east at
a junction on the West India Quay bridge, rocking the first train and throwing
it off the track.
        Police had to erect a ladder to get passengers out of the tilting cars.
        No serious injuries were reported but police said two passengers were
taken to hospital for treatment of shock. One commuter said passengers in the
first train, which was stopped, yelled ``hold on'' and ``watch out'' as the
second driverless train continued toward them.
        ``It was bloody frightening, because you could see it unfolding
before your eyes,'' said commuter Tom Bromhead.
        The Docklands Light Railway, intended to serve thousands of commuters
in the district, usually operates by computer, allowing the drivers to
check tickets and open the doors.
        The newly built system has been plagued by cost overruns and frequent
shutdowns in the growing business district east of London.

Jonathan Kamens, MIT Project Athena   jik@Athena.MIT.EDU	  617-253-8085

------------------------------

Date: Tue, 23 Apr 91 05:39:14 CDT
From: root@nextserver.cs.stthomas.edu (Max Tardiveau)
Subject: No beepers under 21

I saw on a news program (it may have been 48 hours) this weekend that there was
a law being debated in Congress that would forbid the possession of electronic
pagers (beepers) under the age of 21. The idea being that a lot of drug dealers
use these devices.  This strikes me as a perfect example of cause-and-effect
confusion.  How can any mildly intelligent person believe that forbidding the
use of beepers under the age of 21 will in any way affect drug trafficking?  I
would appreciate any detail anyone might have, I am afraid this is all I know,
but it is so mind-boggling I couldn't let it pass unnoticed.

Max Tardiveau, Department of Computer Science, University of St.Thomas,
St.Paul, MN 55105 Internet : m9tardiv@cs.stthomas.edu

     [In a lighter vein [!], almost all beepers around today are under the 
     age of 21.  Maybe the older beepers will sue for age discrimination.  PGN]

------------------------------

Date: Sat, 20 Apr 91 14:52:14 EDT
From: Jerry Leichter <leichter@lrw.com>
Subject: Monitoring in the workplace

The issue of automated monitoring of workers has been discussed many times in
this forum.  The current BusinessWeek (April 29, 1991) provides some important
new information about this practice: As many of us may have suspected, not only
is it bad for employees, it's not even good business.  The article, "How to
Motivate Workers: Don't Watch 'Em" appears as a sidebar (page 56) to a larger
article on white-color work quality (which I recommend, along with an
interesting cover article on the unusability of too many technological objects):

	Electronic eavesdropping is a tempting tool for boosting office
	productivity.  Airlines, insurers, and telecommunications com-
	panies, among others, often clock every second that workers
	spend on computers or on the phone with customers.  From a hand-
	ful a decade ago, the number of monitored employees has reached
	10 million, according to the Office of Technology Assessment.

	But now, the search for quality is abridging this trend.  Federal
	Express, Bell Canada, USAA, and Northwest Airlines, among other
	major employers, are finding that too much speed spoils service.

	HANDLE TIME
	They have begun to stress quality over quantity, or to end moni-
	toring entirely.  THe result seems to be happier customers and
	employees.  Proponents also say that a focus on quality does as
	much as monitoring to keep productivity high and rising.  "A lot
	of people ask, which do you want, quality or quantity?" says
	Rebecca Olson, head of customer service for Federal Express
	Corp.'s southern region.  "We found that you can have both,
	though it took a while to sink in."

	FedEx was among the first to see this.  In 1984, it was worried
	about United Parcel Service Inc.'s move into overnight deliveries.
	Management realized that it could save money by slicing just one
	second off the average time its 2,500 customer-service agents
	spent on each call.  So, FedEx began to monitor the average
	"handle" time per call - and made beating the clock 50% of an
	agent's performance review.

	Two years later, the strategy came home to roost.  Employees griped
	that limiting every call to 140 seconds created too much stress -
	and made them cut of customers before questions were answered....

	A new system cleared that up.  Today, a supervisor listens in on
	a random call twice a year.  Afterward, the discussion with the
	agent focuses on quality:  The length of the call isn't mentioned.
	Both employees and executives say that service has improved -
	without hurting speed.  The average call even dropped to 135 sec-
	onds....

The article continues with a description of another positive result, at Bell
Canada's operator services.
							-- Jerry

------------------------------

Date: Mon, 22 Apr 91 10:30:39 xxx
From: [anonymous]
Subject: "University Exec Backs Hacking" (Dutch crackers, RISKS-11.50,51)

   UTRECHT, Netherlands (AP)
   A Dutch university official on Monday defended a student hacker's purported
use of a computer network used by his school to penetrate a U.S. military
computer.
   The Netherlands has no law against computer intrusion, making it a hacker's
paradise. However, Parliament is expected to pass a law this year that forbids
unauthorized entry into computer systems, the Justice Ministry said.
   The New York Times reported in Sunday editions that over the past six
months, three or four Dutch hackers have broken into a range of U.S.-based
computers. The computers include those at the Pentagon's Pacific Fleet Command,
the Kennedy Space Center, and the Lawrence Livermore National Laboratory and
Stanford University in California.                            [see RISKS-11.50]
   U.S. officials said they had identified some of the intruders, but that no
arrests had been made.
   Maarten Rook, the director of economics and personnel at Utrecht University,
was present during the February filming of a hacking incident shown on a
late-night Dutch television show. It showed the hacker breaking into what
purportedly was a U.S. Navy computer installation in San Diego.
   During the broadcast, the hacker, whose face was not shown and whose voice
was scrambled, linked his personal computer to the Surfnet data network used by
Dutch universities. Surfnet in turn is linked to the U.S.-based Internet
bulletin board, through which the intrusion was made.
   The televised hacker, an Amsterdam student, obtained data that he claimed
pertained to U.S. Navy ships and ballistic missiles, said Rook. However, Rook
said he did not believe that the break-in resulted in access to confidential
information.
   It could not be determined if the target of the televised break-in was the
Pacific Fleet Command computer.
   Rook said installations using computers had a responsibility to devise
secure systems to protect themselves against hackers.  "They should take care
of their own secrets ... If they don't want to be called they shouldn't be
hooked up to the system," he said.  Rook said most Dutch universities encourage
their students to probe other systems as much as they can as part of their
computer training.  Several years ago, the prestigious Delft University of
Technology even offered a course in computer hacking.  "In our teaching system
we try to endorse exploration and make our students enthusiastic about it," he
told The Associated Press.

------------------------------

Date: Tue, 23 Apr 91 03:35 MET
From: "Herman J. Woltring" <UGDIST@nici.kun.nl>
Subject: Hacking a la Neerlandaise

Last week, I committed a series of terrible crimes.  While sitting behind my PC
in the wee hours of the night, I hacked into a number of university and
military libraries all over the world, both in the USA and in Australia, using
the TELNET facilities recently advertised in the bimonthly SURFnet Bulletin
from SURFnet Inc of Utrecht, The Netherlands.  In this manner, I was able to
snoop around on the shelves of these libraries, and to find out what books were
on hold, booked for borrowing, not to be removed from the premises, or free to
be lent for shorter or longer periods.

In this way, I was able to pry into the librarians' private domains, well
beyond the reach of American and Australian Law.  Since the Gouvernment of The
Netherlands is trying hard to persuade Parliament that Computer Hacking is a
capital offence, it is my solemn duty to ask the Dutch Press to film and
publicly denounce my asocial behaviour, so as to convince the Legislative that
the proposed revision of the Netherlands Penal Code is timely and quite
appropriate.  Even worse, SURFnet Inc has been aiding and abetting with my
crime, because instructions on how to hack into these overseas computers are
freely available by networking.  Just sending the one-line query GET INTERLIB
CATALOG to LISTSERV@NIC.SURFNET.NL (or to LISTSERV@HEARN.BITNET) will provide
all information needed for TELNETting, FTPing, and similar lone-ranging com-
puter intrusion activities.  It is particularly shocking that the INTERLIB
CATALOG even provides login-in data and passwords such as "anonymous" or
"guest".

Herman J. Woltring  <ugdist@hnykun53.bitnet,  ugdist@nici.kun.nl>
Eindhoven, The Netherlands  (50 km SSE from Utrecht/NL)

------------------------------

Date: Tue, 23 Apr 91 11:30:35 EDT
From: pereira@klee.research.att.com (Fernando Pereira)
Subject: Responsibilities of Internet sites (was Dutch crackers)

I don't want to start a whole discussion on this matter, which has in other
guises been covered extensively on previous RISKs, but I would like to respond
briefly to T. Blinn and L. T. Heberlein's responses to my recent posting.

1) I know of no area of human activity in which wilfull intrusion or condoning
intrusion are seen as no more condemnable as failure to protect one's domain
from intrusion to the best of one's ability.  Furthermore, it has been often
pointed out that many Internet sites, for economic or other reasons, do not
have the resources to keep up with security updates. The Internet has never
been seen as a secure environment, to my knowledge. In fact, one might well
take it as an wide-open environment in whose existence depends on the restraint
and common courtesy of its users. Those that do not understand these ground
rules don't belong there.

2) Indeed there are intruders all over the place. The special issue with
respect to Utrecht is that an official of that site condoned behavior harmful
to the community of Internet users.

Fernando Pereira, 2D-447, AT&T Bell Laboratories 
600 Mountain Ave, Murray Hill, NJ 07974               pereira@research.att.com

------------------------------

Date: Mon, 22 Apr 91 22:38:43 EDT
From: smb@ulysses.att.com
Subject: Re: Dutch crackers and irresponsible officials (RISKS-11.50)

I think that Thomas Blinn has missed the point.  Yes, systems on the Internet
are insecure, often to a scandalous degree.  And yes, that's often the fault of
careless or irresponsible system administrators, though vendor culpability
should not be neglected.  Disregarding for a moment the activities of the
hackers, the offense committed by the Dutch university officials is ethical:
they are failing to condemn activities that are at the least immoral, and at
best downright criminal.

The traditional defenses of hackers simply do not apply here, assuming that the
facts have been reported accurately.  There was no ingenuity or exploration
demonstrated; we are told that the intruder appeared to have a ``cookbook
sitting next to him telling him what to do next at each step.''  Nor was the
intrusion harmless; the article mentions tampering with data.  Under what moral
codes are such activities acceptable?  Arguably, a university is not the place
to teach basic ethical behavior; it should have been learned long before.  But
there is at the very least the imperative to refrain from encouraging unethical
behavior.  I will agree that some forms of hacking are educational.  Given
that, schools should provide the proper targets to be probed.  (By analogy, I
have not heard of locksmith schools urging students to engage in unofficial lab
sessions at the neighborhood bank.  Why is this different?)

Before I return to the ``merely'' technical, let me belabor the obvious one
more time.  A landowner (in the U.S.) who does not wish visitors may simply
post ``No Trespassing'' signs; he or she is under no obligation, legal or
moral, to install barbed-wire fences.  To be sure, if the person is
sufficiently concerned about privacy or protection of property, stronger
measures may be taken, with the distinct encouragement of the insurance
companies.  So what?  A lack of prudence (or paranoia) is not an invitation to
burglary.

Let us now consider the problem of insecure systems.  Yes, they exist.  Often,
there's no justification for that, especially when the holes are as well-known
as the ones apparently used here.  But system administrators are often
overworked, and -- most important -- computer systems do not exist for the
purpose of being secure, any more than cars exist for the purpose of being
locked.  A computer system has a mission, an end-user community to serve.  If
its mission involves an application that won't run on a later version of the
operating system -- and we've all seen those -- the operating system won't be
(and shouldn't be) changed.  Very often, no one has the time or energy to
upgrade things, especially when the current applications are running
satisfactorily.  Are the latest security bug fixes even available for old
releases?  Does the vendor even have the capability to perform thorough testing
on such fixes?  Very often, with the best will in the world, the answer is
``no''.

The claim has been made on RISKS that vendors should warrant their systems to
be bug-free, just as is done for other products.  Presumably, this applies even
more to security holes.  I have my doubts that this can be done -- I just don't
think the state of the art of software engineering is good enough.  (If it were
that good, much of the RISKS digest would go away....) For the forseeable
future, we will be faced with systems that, most likely, have serious holes.
Administrators of systems containing precious data react by withdrawing them
from the electronic community, or hide them behind gateways.  Others venture
forth, but keep their alarms on and their phasers at the ready.  Still others
place their trust in the shared values of the electronic community, and take
only minimal precautions.  And that trust still exists, at least in the minds
of some users.  A quick quiz: how many readers will set up a ``vacation''
message announcing how long they'll be away, and where they're going?  How many
people would put the same information on their home answering machines?  In a
sign on the front door of their houses?

Yes, computer security is important.  (I certainly think so; it's my area of
research.)  And yes, people shouldn't be surprised when loosely-administered
systems are hacked, any more than than they should be surprised at muggings in
some of the more dubious neighborhoods.  But it is a fallacy, I think, to
equate lack of prudence with solicitation to intrusion.
                                         		  --Steve Bellovin

------------------------------

Date: Tue, 23 Apr 91 10:09:30 PDT
From: haz@leland.stanford.edu
Subject: Re: Dutch crackers and irresponsible officials (RISKS-11.50)

In reference to Mr. Blinn's letter, to call administrators of computers
irresponsible for allowing "well-known" security holes to continue to exist is
understandable.  No one wants "bad guys" to have bases from which they can
mount more systematic attacks on other, perhaps more secure, machines.

However, you are missing the point.  When an intruder is detected, what is the
appropriate response?  Should one make an effort to locate the muncher at all?
If not to punish him/her, then simply to thank them for pointing out the flaws
in your system, and then proceed to close the opened holes?

Given the complexity of today's networked systems, it is no more easy to secure
a computer than it is to secure one's own home.  It seems that the same code of
ethics should apply.  One shouldn't be faulted for having failed to implement
the latest security patch any more than one should be faulted for not having
locked all the windows, not having high security locks, and not having
deadbolts in place.

What we are discussing here, is a case of someone who has been breaking into
computer systems, and has, to some degree, been LOCATED.  Given the time scales
mentioned in the NYT article, the feds had known for six months about the
intrusion, and had begun relatively sophisticated work to attempt to track down
the intruder, and succeeded, only to discover that they could not actually
pursue legal recourse.

An analogy might be an anonymous flasher (who does no actual physical damage,
but is potentially disruptive) who turns out to be a teenager of the family
down the street.  The question is whether the family has a responsibility to
discipline their children or not.
                                  -castor fu    castor@embezzle.stanford.edu

------------------------------

Date: 23 Apr 91 12:57:07 GMT
From: oneel@heawk1.rosserv.gsfc.nasa.gov ( Bruce Oneel )
Subject: re: Dutch hackers and KSC [Kennedy Space Center]

I don't believe that KSC is on the internet.                          bruce

Bruce O'Neel, Code 664/STX,NASA/GSFC Bld 28/W281, Greenbelt  MD 20771 
(301)-286-4585    compuserve: 72737,1315    oneel@heasfs.gsfc.nasa.gov

------------------------------

Date:  Fri, 19 Apr 91 22:42 EDT
From: WHMurray@DOCKMASTER.NCSC.MIL
Subject: CERT Warning on Spoofs

A recent RISKS carried a warning by the CERT about spoofs.  Reading it you
might conclude that they were surprised by these nasty attacks.  (I described
these spoofs, at least in abstract terms, in "IEEE Spectrum" more than a decade
ago.  Landreth described them in elaborate detail in "Out of the Inner Circle"
at about the same time.)  The CERT proposed a remedy which was labelled in
RISKS as "Social Engineering."

By labelling their remedy "Social Engineering," I expect that the CERT intended
to suggest that the problem of vulnerability to spoofs is one of human
behavior.  Nonetheless, whether they intended to or not, what they succeeded in
communicating was the futility of their remedy.  While it is possible to
protect a user from a spoof by warning him about it, you cannot adequately
protect a system with a large user population by doing so.

It is attributed to Phineas T. Barnum: "There is a sucker born every minute."
Far fewer than that are required to defeat the CERT's remedy.  Certainly there
are more than enough in the user population of any large system, let alone the
internet, to ensure that all those systems that rely upon reusable passwords
can be compromised by even a trivial spoof.

Lincoln said "Human nature will not change."  If Lincoln was wrong, it is
because human nature changes too slowly to notice.  The CERT, and the system
managers it is exhorting, are not likely to change it in time to cope with
these attacks.  In attempting to solve the problem of spoofs by changing user
gullibility, the CERT is attempting to prop up a house of cards.

While the problem of these spoofs is aggravated by user behavior rooted in
reusable passwords.  Reusable passwords are fundamentally flawed: they have
lasting value and the right to use them includes the right to make and give
away, accidentally or intentionally, both the password and the associated
privileges.  Spoofs, and all other attacks against passwords, rely upon these
two flaws for their efficiency.  One can afford to attack them because they
have residual value.  The success of the attack does not deny the password's
use to the legitimate user, so he is not bound, or even likely, to notice.

The reliance on reusable passwords is the biggest single computer security
vulnerability that we have.  It dwarfs all others.  It finesses all our other
efforts; nothing else that we do is effective as long we are vulnerable to
these spoofs.  Continued exclusive reliance on reusable passwords puts all our
systems at hazard.  Indeed it puts public and management confidence in our
systems at hazard.

While spoofs are favored by insiders, most of the highly publicized
penetrations by outsiders have involved attacks against reusable passwords.
While most of these began with attacks against weak passwords, many
subsequently went on to spoofs in order to expand the attacker's new
privileges.

The solution to this problem will not be found in trying to change user
behavior; while it is a fundamental condition of the problem, it is not one
that is subject to change.  The solution will be found in one-time passwords.
If the CERT really wants to address the problem, it will recommend something
that has a chance of success.  It will recommend the use of reusable passwords.

They can enjoy the distinction of being the first authoritative institution to
do so.  (NIST has not done so, in spite of persistent urging from yours truly.
NCSC has not done so, though of course they use them on their own systems.  IBM
has not done so, though they have said that they will not do anything to
discourage or inhibit their use nor to favor one product over another.)

While there continue to be environments and applications in which reusable
passwords can be made to work, they do not include the internet or user
programming.  While one-time passwords are not free, they are effcient; their
use covers their own cost.  Their cost is trivial when compared to other costs
of using computers, and when compared to the cost of continued exclusive
reliance on reusable passwords.  Their cost is regular and predictable,
particularly when compared to the cost of the uncertainties against which they
protect.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

------------------------------

Date: Fri, 19 Apr 91 23:44:47 GMT
From: Iain Douglas <iain@tharr.UUCP>
Subject: Broadcast telephone calls

Thursday evening (18-4-91 ) the BBC popular science program Tomorrow's World
ran an article of particular interest.  Reserchers for British Telecom have
developed a system that uses tuneable lasers and optical fibres to connect
telephone calls. Each subscriber is allocated a frequency, and when making a
call the umber you dial tunes up the subscribers frequency on the laser in your
phone. Gone is the electromechanical and electronic switching gear currently in
use, all calls are BROADCAST across the whole system.  Nobody is going to
produce a reciever that is tuneable over the whole bandwidth, are they?  :-)

Iain

------------------------------

Date: Wed, 13 Mar 91 03:06:59 PST
From: ts@cup.portal.com
Subject: Parity and SCSI (RISKS-11.18,22)

Martin Minow recently wrote in RISKS about the lack of error detection in SCSI.

In practice, this does not seem to be a problem.  Each data byte has a parity
bit associated with it.  Thus, you would need two or more errors in a single
byte to cause a problem.

In three years of extensive SCSI use (I work for a company that writes firmware
for SCSI host adaptors and SCSI target devices), including very badly wire
wrapped prototypes, I've never seen a single random error, let alone multiple
errors in a single byte.

The only times I've seen an error is when something like a cable or a pin
breaks, causing a stuck bit.  Parity catches these very quickly.

No one else in the company has seen an error either, and at SCSI-2 standard
committee meetings and CAM committee meetings we've asked other people, and
they too report that errors are very rare.
                      				     Tim Smith

------------------------------

End of RISKS-FORUM Digest 11.52
************************