Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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.
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)
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
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åk, Department of Electrical Engineering, Linköping University S-581 83 Linköping Sweden +46 13 281722 Viiveke@isy.liu.se
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.
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.
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)
> 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 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"
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.xThe 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.
Please report problems with the web pages to the maintainer