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 18 Issue 7

Thursday 25 April 1996

Contents

o Former Oracle worker charged with perjury: bogus e-mail
PGN
o A reminder about letter bombs in MSW6.0 [name withheld by request]
o AOL censors British town's name!
Clive Feather
Rob Kling
o Re: Swedish court fines parents for son's overly long name
Viiveke F?k
Gunnar Pettersson
o Computers and Social Unrest
Carl Wittnebert
o When the Clock Strikes 2000
Edupage
o Re: MCI recommending bad security practices
Peter Scott
o Society and the Future of Computing '96, 16-19 Jun 1996, Snowbird, UT
Jeffrey Johnson
o CERT (sm) Advisory CA-96.09, Vulnerability in rpc.statd
CERT
o Info on RISKS (comp.risks)

Former Oracle worker charged with perjury: bogus e-mail

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 23 Apr 96 17:58:50 PDT
Adelyn Lee had won a $100K out-of-court settlement for wrongful termination
from Oracle in February 1995, claiming that she had been fired for refusing
to have sex with Oracle president Larry Ellison.  She had apparently used as
evidence a piece of e-mail from her boss VP Craig Ramsey to Ellison,
confirming that Lee had been terminated as per Ellison's request.  To make a
long story short, San Mateo County Deputy District Attorney Paul Wasserman
said that their investigation has now come to the conclusion that Ramsey
could not have sent the e-mail (because he was driving in his car at the time
according to cell-phone records) and that, as Ramsey's executive assistant,
Lee knew his passwords (and indeed had been responsible for changing them for
him periodically).  Lee has now been charged with felony perjury for lying
and sending false e-mail.  [Source: *San Francisco Chronicle*, 20 Apr 1996,
D1-2]

What are some of the conclusions for RISKS readers (not new)?

  1. Don't believe e-mail FROM: headers accurately represent the sender.
  2. Don't believe the content of e-mail, whether or not the headers
     are correct.
  3. Don't share your passwords overtly with anyone, or let someone else
     be responsible for your passwords.
  4. Don't use covertly compromisible reusable fixed passwords; how often
     you change them is more or less irrelevant.
  5. Use one-time nonreusable authentication tokens instead of fixed passwords.
  6. Even if you use PEM, PGP, stronger-crypto e-mail, or whatever, you
     cannot ensure authenticity, because of untrustworthy operating systems
     and untrustworthy users.
  7. Beware of trying to use e-mail as nonrepudiatable court evidence.
  8. HOWEVER, don't believe that cell-phone records are valid as court
     evidence; they too could be bogus or altered.  If someone drags you
     into court, find someone who can demonstrate how easily those records
     could have been altered!
  9. Etc., etc., etc.


A reminder about letter bombs in MSW6.0

<"[name withheld by request]">
Tue, 23 Apr 96 17:58:50 PDT
Today I got e-mail from Agptacek@aol.com.  I have never received e-mail from
this account before.  I have no idea who it is.  All I got was the message
below --- "Pls. find file attached." --- plus a Microsoft Word 6.0 file.

Now, anybody who has been following the stuff with MSW6.0 knows that
executable code can be hidden in MSW6.0 files. Perhaps code to delete my
files. Or give me a new virus.  [Or a nasty Trojan horse.]

Do you trust e-mail that anybody sends you?

>From: Agptacek@aol.com
>Date: Wed, 24 Apr 1996 01:02:03 -0400
>To: ***********
>Subject: Discovery Records
>MIME-Version: 1.0
>
>Content-ID: <0_18723_830322121@emout07.mail.aol.com.30083>
>Content-type: text/plain
>
>Pls. find file attached.
>
>Content-ID: <0_18723_830322121@emout07.mail.aol.com.30084>
>Content-type: application/applefile;
>        name="Discovery";
>        X-Mac-Creator="4d535744";
>        X-Mac-Type="5736424e"
>
>Attachment converted: Asher:Discovery 1 (W6BN/MSWD) (00008B8A)


AOL censors British town's name!

Clive Feather <cdwf@cityscape.co.uk>
Wed, 17 Apr 1996 15:28:52 +0100 (BST)
  [Clive forwarded to RISKS an long item from the Computer underground Digest,
  Thu Apr 11, 1996, Volume 8 : Issue 29, ISSN 1004-042X, from Doug Blackie
  <STEELBEAT@aol.com> that relates an experience Doug had in trying to
  register with AOL.  He entered his name "Blackie" and his home town
  "Scunthorpe", and found that AOL's (indecency-filtering) registration
  program would not accept that combination.  After various discussions with
  the AOL folks in Dublin, he discovered that he could register properly if
  he entered the town as "Sconthorpe".  As a result of this curious situation,
  AOL has announced that the name of the town will henceforth be known as
  "Sconthorpe".  The entire saga is documented in the Scunthorpe Evening
  Telegraph (final edition) of Tuesday, 9 Apr 1996, issue number 30111,
  printed and published by Grimsby and Scunthorpe Newspapers Ltd., Telegraph
  House, Doncaster Road, Scunthorpe, DN15 7RE, UK.  The article was provided
  on-line by David G. Bell <dbell@zhochaka.demon.co.uk>, and was included as
  a part of Doug Blackie's message.  PGN Abstracting.]


Re: AOL censors town's name!

Rob Kling <kling@ics.uci.edu>
Thu, 25 Apr 1996 11:10:22 -0700
  [The previous item contributed by Clive Feather touches on some further
  serious issues relating to the effectiveness, propriety, and risks
  involved in filters that attempt to censor on the basis of linguistic
  strings; as other examples, side-effects of filtering "couples"
  (RISKS-17.79) and "xxx" (SurfWatch, RISKS-17.81) have been noted in recent
  RISKS postings.

  Rob Kling is a member of the ACM Committee on Computers and Public Policy,
  the umbrella organization in ACM for RISKS.  He had the following comments
  upon seeing the above message; his comments address just a few of the RISKS
  issues raised.  PGN]

There is a lot of info regarding Scunthorpe obtainable via Alta Vista.
This is a real city and its integrity deserves respect, even if it is
not exactly a place well-known to people in the US.  [For example, see
http://www.computerprint.co.uk/scunthorpe/travel.html and
http://www.computerprint.co.uk/scunthorpe/history.html .]

I can imagine that there might even be some people with the last name of
Scunthorpe.  The willingness of AOL (or other services) to excise identities
in the name of "decency" raises big issues of genuine decency in my view.

Rob Kling


Re: Swedish court fines parents for son's overly long name

?= a letter UNIX can't handle) Wed, 24 Apr 1996 08:52:41 +0200
The law in question states that parents should report the name they have
chosen for their children within a specified time after birth (three months
I think).  The authorities in their turn has a rule saying that they should
not allow registration of names that are likely to cause harassment or other
obvious drawbacks for the child, like giving a girl what is traditionally
exclusively a boy's name and vice versa.  Another recent case was when
parents were not allowed to name their girl Ikea (a constructed name for a
fairly well-known furniture company) and an older example was when another
girl could not be named Veranda (which means exactly the same in Swedish).

What has this got to do with computers and risks? The parent's choice of
name in this case is a protest against bureaucracy in general, one part of
which is that the authorities have indeed a limit on how many characters
that they register for each child.  (The row of letters is as impossible to
pronounce in Swedish as it is in English.  Albin is of course a perfectly
valid name here too.)

As for computers and real risks, this is an international question about
assumptions of name structure and their use in design of computer systems.
We often even can't handle our own in Sweden.  Swedes for example typically
have from one to three first names, and they choose themselves which one
that they use daily.  That choice is reported, but many computer systems do
not register it.  Normally it is the first "first name", but not
necessarily.  Which means that there are mix-ups, when for example a
computer sends a letter to George Thomas Smith addressed to "George Smith",
and that happens to be what the father is not called (he uses his second
name Thomas) but it also happens to be what the son (Andrew Charles George
Smith) actually is called.  This happened in my husband's family, and guess
how much trouble there was when the son tried to report that he was moving
to a new address...  As for myself, I sometimes give in and register my
second "first name" as "middle name" when travelling, so that passport
authorities do not complain that I do have a "middle name" and should fill
it in.  But if you come to Sweden and marry someone here, it is very likely
that you can not register that child's middle name, because it is
"offensive" as a first name, and we only register first and family names.

Viiveke F=E5k, Department of Electrical Engineering, Link=F6ping University
S-581 83 Link=F6ping  Sweden    +46 13 281722  Viiveke@isy.liu.se

  [Incidentally, Albin's would-be given name (noted in RISKS-18.06)
  had one occurrence of the putatively heinous "xxx".  Perhaps we
  will all someday have to be identified by multilingually and
  transnationally filtered globally biunique identifiers -- to
  accommodate our computer systems.   (Note that Internet addresses and
  phone numbers are unique if globally qualified, but are not biunique
  -- because they may be shared by multiple personalities).  PGN]


Re: Swedish court fines parents for son's overly long name (R-18.06)

Gunnar Pettersson <gunnar.pettersson@powrd.demon.co.uk>
Thu, 25 Apr 1996 16:59:09 +0000
The law that was broken is the Swedish 'Name Law' (SFS 1982:670) and the
authority which deals with its implementation is the Swedish Patent &
Registration Office.

Not having seen the detailed judgement in this case, I would guess that the
law was seen to have been broken in at least two ways. First a technical
reason: as your correspondent surmises, the name would have been regarded
as far too unmanageable for inclusion in the computerized Civic
Registration data held on all Swedish citizens. Secondly, and perhaps more
importantly, the law explicitly prohibits forenames "which can cause
offence, or may lead to any inconvenience for the bearer, or is for any
other reason obviously unsuitable as a forename".

As far as the meaning of the name 'Brfxxx...' is concerned, I would have
thought it is to be found precisely in its lack of meaning. And, whatever
one thinks of a law like the Swedish one, what about the poor kid himself?
Cases like this one tend to prove very little about the law itself, and much
more about the pretty warped attitude some people have towards their
offspring...

The Swedish name law, on which most other Nordic name laws are based, is
nonetheless unusually restrictive as far as choosing and changing names are
concerned. However, it should be pointed out that practically every other
country, with the exception of the UK and parts of the US, have *some* form
of restriction on names: e.g. Germans can't change their names to Hitler;
French forenames must be taken from saints and/or antiquity; etc. etc.

In Nov 1992, I wrote and presented a talk on BBC radio, "Names Never Hurt
You", which deals with the social and political aspects of name laws, with
particular emphasis on Sweden. If anyone would like a transcript, please
e-mail me.


Computers and Social Unrest

Carl Wittnebert <cewit@wco.com>
Thu, 25 Apr 1996 04:09:05 -0700 (PDT)
A potentially earthshaking risk of using computers is currently being
discussed at the highest levels of the U. S. government.  The risk involves
human skill obsolescence, a growing wage gap between skilled and unskilled
workers, and possible social unrest.  The phenomenon may underlie the themes
of economic nationalism and protectionism that have surfaced during the
current Presidential campaign.

The *Wall Street Journal* devoted a front-page column to the topic on 22 Apr
1996.  It quoted Federal Reserve Board Chairman Alan Greenspan as saying,
"Human skills are subject to obsolescence at a rate perhaps unprecedented in
American history."  It went on to quote George David, chief executive officer
at United Technologies Corp., who believes that 18 million U.S.  workers are
"at risk" because their jobs are "prone to automation."

Upheaval in the nature of work--in manufacturing in the 1980's, and now in
the service sector--has been discussed for some time, usually under the
assumption that additional jobs would be created to replace the ones lost to
machines.  Increasingly, the question is arising as to just how much the new
jobs are going to pay.


When the Clock Strikes 2000 (Edupage, 23 Apr 1996)

Edupage Editors <educom@elanor.oit.unc.edu>
Tue, 23 Apr 1996 17:34:05 -0400 (EDT)
The Gartner Group in Stamford, Connecticut, says the federal government will
spend about $30 billion to modify a massive number of computer programs in
which years were coded simply as two-digit numbers (without identifying the
century) and which will have to be fixed so that they can correctly calculate
things like benefits payments.  It is also estimated that by the time the
year 2000 comes around only 70% of government computer programs will have
been modified to deal with the problem.  (*Computerworld*, 22 Apr 1996 p1)
[See RISKS-17.82 for global estimates of something around half a trillion
dollars, also from the Gartner Group.  PGN]


Re: MCI recommending bad security practices (McDaniel, RISKS-18.06)

Peter Scott <pjscott@euclid.Jpl.Nasa.Gov>
Wed, 24 Apr 1996 09:33:51 -0700
> For some strange reason MCI is recommending you to do exactly the opposite
> of what good security practices would proscribe! Not only do they suggest
                                          ^
Now there's an example of a misspelling-type RISK [reversing the meaning!].

Peter Scott, NASA/JPL/Caltech   Peter.J.Scott@jpl.nasa.gov


Society and the Future of Computing '96, 16-19 Jun 1996, Snowbird, UT

Jeff Johnson <Jeffrey.Johnson@Eng.Sun.COM>
Thu, 25 Apr 1996 10:06:56 -0700
        Society and the Future of Computing '96
                June 16-20, 1996
                Cliff Lodge
                Snowbird, Utah
             http://www.lanl.gov/SFC

Sponsor: USACM.  Contact Rick Light, Los Alamos National Lab, MS B294,
Group CIC-7, Los Alamos, NM 87545, phone 505/667-0744, e-mail
rxl@lanl.gov, Web: http://www.lanl.gov/SFC/96/sfcHome.html.

This conference provides a multidisciplinary forum to articulate novel
research directions that advance computer science in ways that are truly
beneficial to society.  Participants will share, explore, and demonstrate
the responsible use of advanced scientific computing and National
Information Infrastructure (NII) Program technologies for the benefit of
diverse communities.

The conference structure includes keynote speakers, panels of invited
speakers in which attendees and the panelists engage each other in open
discussions of the issues, interactive poster presentations, debates, and
workshops.  The intent is to share ideas in a multidisciplinary environment
for mutual enrichment and learning, ultimately to affect the directions of
computer science research and applications for the benefit of all.  The
conference Web site includes the preliminary conference agenda and will
continue to provide the latest information as the conference design unfolds.

Keynote speakers:
        Tom Landauer, U. of Colorado (Boulder): "Computers, Usefulness,
          Usability, Productivity, and Happiness"
        Laura Breeden, formerly of of US Commerce Dept. NTIA: "Whose
          Voice is Heard?  Listening to the Computer and Communications
          Revolution"
        Bill Wulf, University of Virginia: "Information Technology
          is the Lever, But Where Shall We Stand?"
Panels:
        Creating the Future: Computer Industry Research Lab Heads
          Rick Light, Moderator
        Working in the Networked Economy: Issues
          Gary Chapman, Moderator
        Working in the Networked Economy: Opportunities
          Phil Agre, Moderator
        Contrasting Images of the Future
          Allan Kuchinsky, Moderator
        The European Information Society (live from Europe)
          Terry Bynum, Moderator
        If Anyone Can Publish, Who Will Edit?
          Karen Coyle, Moderator
        On the Internet, No One Knows You're a Dog
          Brenda Allen, Moderator
        Government On-Line: Report Card and Futures
          Charles Brownstein, Moderator
Workshops:
        Shneiderman: "The Durango Declaration Continued: Toward
          a Snowbird Conference Statement"
        Cisler, Uncapher, Press: "Implications of the Net for Industrialized
           Countries, Developing Nations, and Indigenous Cultures"
        Epstein: "Emerging Realities, Virtual and Otherwise"
        Meyer: "Anthropology and Computer Technologies"


CERT (sm) Advisory CA-96.09, 24 Apr 1996, Vulnerability in rpc.statd

CERT Advisory <cert-advisory@cert.org>
Wed, 24 Apr 1996 14:25:09 -0400
The CERT Coordination Center has received reports of a vulnerability in
rpc.statd (rpc.statd is also known as statd on some systems). As of the
date of this advisory, we have received no reports of this vulnerability
being exploited.

If exploited, this vulnerability can be used to remove any file that the
root user can remove or to create any file that the root user can
create.

Section III and Appendix A contain information from vendors. Appendix B
contains an example of a possible workaround.

As we receive additional information relating to this advisory, we will
place it in

        ftp://info.cert.org/pub/cert_advisories/CA-96.09.README

We encourage you to check our README files regularly for updates on
advisories that relate to your site.

I.   Description

     rpc.statd, also called statd, is the NFS file-locking status monitor. It
     interacts with rpc.lockd, also called lockd, to provide the crash and
     recovery functions for file locking across NFS.

     NFS is stateless, which means that NFS clients and servers can be
     rebooted without a loss of file integrity due to NFS. In contrast, NFS
     file locking is stateful. To achieve this stateful nature in a stateless
     environment, rpc.lockd must work with rpc.statd to add state to file
     locking.

     To understand what rpc.statd does, it is first necessary to understand
     what rpc.lockd does. rpc.lockd processes lock requests that are sent
     either locally by the kernel or remotely by another lock daemon.
     rpc.lockd forwards lock requests for remote NFS files to the NFS server's
     lock daemon using Remote Procedure Calls (RPC).

     rpc.lockd then requests monitoring service from the status monitor
     daemon, rpc.statd, running on the NFS server. Monitoring services are
     needed because file locks are maintained in the NFS server kernel. In
     the event of a system crash or reboot, all NFS locks would normally be
     lost. It is rpc.statd that adds stateful file locking.

     When an NFS server reboots, rpc.statd causes the previously held locks
     to be recovered by notifying the NFS client lock daemons to resubmit
     previously granted lock requests. If a lock daemon fails to secure a
     previously granted lock on the NFS server, it sends SIGLOST to the
     process that originally requested the file lock.

     The vulnerability in rpc.statd is its lack of validation of the
     information it receives from what is presumed to be the remote rpc.lockd.
     Because rpc.statd normally runs as root and because it does not validate
     this information, rpc.statd can be made to remove or create any file that
     the root user can remove or create on the NFS server.

II.  Impact

     Any file that root could remove can be removed by rpc.statd. Any file
     that root could create can be created by rpc.statd, albeit with mode 200.

III. Solution

     The general solution to this problem is to replace the rpc.statd daemon
     with one that validates the information sent to it by the remote
     rpc.lockd. We recommend that you install a patch from your vendor if
     possible. If a patch is not available for your system, we recommend
     contacting your vendor and requesting that a patch be developed as soon
     as possible. In the meantime, consider whether the information in
     Appendix B is applicable to your site.


     Vendor Information
     ------------------
     Below is a summary list of the vendors who have reported to us as of the
     date of this advisory.

     Patch information and other details are in Appendix A of this advisory
     and reproduced in the CA-96.09.README file. We will update the README
     file as we receive more information.

     If your vendor's name is not on this list, please contact the vendor
     directly.


     Vendor                           Status
     ------                           ------------
     Apple Computer, Inc.             vulnerable - A/UX version 3.1.1 and
                                        earlier; AIX 4.1.4 for the Apple
                                        Network Server
     Berkeley Software Design, Inc.   not vulnerable - BSD/OS
     Cray Research, Inc.              vulnerable - Unicos version 9.0 and
                                        higher
     Data General Corporation         vulnerable - DG/UX R4.11
     Digital Equipment Corporation    vulnerable - UNIX (OSF/1) V3.0 through
                                        V3.2d; ULTRIX V4.3 through V4.5
     Harris Computer Systems Corp.    vulnerable - all versions of NightHawk
                                        CX/UX and PowerUX
                                      not vulnerable - all versions of
                                        NightHawk CX/SX and CyberGuard CX/SX
     Hewlett-Packard Company          vulnerable - 9.X and 10.X
     IBM Corporation                  vulnerable - AIX 3.2 and 4.1
     NEC Corporation                  some systems vulnerable
     NeXT Software, Inc.              vulnerable - versions before 4.0;
                                        will be fixed in 4.0
     The Santa Cruz Operation, Inc.   not vulnerable -  SCO UnixWare 2.x.;
                                       SCO OpenServer 3.0, 5; SCO Open Desktop
                                       2.x, 3.x; SCO NFS 1.x.x.
     Silicon Graphics, Inc.           vulnerable - all versions of IRIX except
                                        6.2
                                      not vulnerable - IRIX 6.2
     Sony Corporation                 vulnerable - NEWS-OS 4.2.1, 6.0.3, 6.1,
                                        and 6.1.1
     Sun Microsystems, Inc.           believed to be vulnerable - SunOS 4.x
                                        and Solaris 2.x

The CERT Coordination Center thanks Andrew Gross of the San Diego
Supercomputer Center for reporting this problem and Wolfgang Ley of DFN-CERT
for his support in responding to this problem.

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident
Response and Security Teams (FIRST).

We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact the
CERT staff for more information.

Location of CERT PGP key
         ftp://info.cert.org/pub/CERT_PGP.key

CERT Contact Information
Email    cert@cert.org
Phone    +1 412-268-7090 (24-hour hotline)
                CERT personnel answer 8:30-5:00 p.m. EST
                (GMT-5)/EDT(GMT-4), and are on call for
                emergencies during other hours.
Fax      +1 412-268-6989

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

CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
        http://www.cert.org/
        ftp://info.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 CERT advisories and bulletins, send your
email address to
        cert-advisory-request@cert.org

Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.

CERT is a service mark of Carnegie Mellon University.

  [Appendices removed for RISKS.]

Please report problems with the web pages to the maintainer

Top