precedence: bulk Subject: RISKS DIGEST 19.57 RISKS-LIST: Risks-Forum Digest Monday 26 January 1998 Volume 19 : Issue 57 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** Contents: Air Force thinks push-pull technology too risky (Edupage) Risks of Transit Automation (Dave Pierson) OSS Risks, Bell Atlantic forgets AT&T charges in phone bill (Robert J. Perillo) robots.txt: ``Here is what I am not telling you.'' (Bertrand Meyer) Each step makes sense, but the result is broken (Cliff Sojourner) Y2K correction at IRS threatens 1,000 taxpayers (Mich Kabay) Y2K bug may lead to lawsuits (John Mainwaring) Y2K affects miniature enthusiasts (Lee Ann Rucker) Risks of making assumptions on education (Joe Thompson) Possible Netscape source code risks (John Wilson) Filing for divorce on the Internet (Steven M. Bellovin) Re: CyberSitter to the rescue (Nick Brown, Leonard Erickson) GPS position accuracy and EGPWS (Ron Crandall) CERT Advisory CA-98.02: Vulnerabilities in CDE (CERT) Re: Software Engineering Code of Ethics (Don Gotterbarn) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 25 Jan 1998 14:37:28 -0500 From: Edupage Editors Subject: Air Force thinks push-pull technology too risky 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) ------------------------------ Date: Sat, 24 Jan 98 17:17:29 EST From: pierson@gone.ENET.dec.com Subject: Risks of Transit Automation 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 ------------------------------ Date: Fri, 23 Jan 98 22:36 EST From: Perillo@DOCKMASTER.NCSC.MIL Subject: OSS Risks, Bell Atlantic forgets AT&T charges in phone bill 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] ------------------------------ Date: Sun, 25 Jan 98 15:04:03 PST From: bertrand@eiffel.com (Bertrand Meyer) Subject: robots.txt: ``Here is what I am not telling you.'' 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 , http://www.eiffel.com [* ... at least not without exploiting various security flaws. PGN] ------------------------------ Date: Wed, 21 Jan 1998 15:41:13 -0800 From: Cliff Sojourner Subject: Each step makes sense, but the result is broken 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/ ------------------------------ Date: Mon, 26 Jan 1998 09:01:53 -0500 From: "Mich Kabay [ICSA]" Subject: Y2K correction at IRS threatens 1,000 taxpayers 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) ------------------------------ Date: 26 Jan 1998 16:56 EST From: "John Mainwaring" Subject: Y2K bug may lead to lawsuits 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 ------------------------------ Date: Fri, 23 Jan 98 14:36:31 -0800 From: Lee Ann Rucker Subject: Y2K affects miniature enthusiasts [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 [I wonder if hyperactive miniature poodles can belong to NAME? They are certainly miniature and they are also enthusiastic. PGN] ------------------------------ Date: Sun, 25 Jan 1998 11:56:31 -0500 From: abuse@orion-com.com (Joe Thompson) Subject: Risks of making assumptions on education (Wolper, RISKS-19.56) 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/ ------------------------------ Date: Thu, 22 Jan 1998 21:43:24 -0500 From: John Wilson Subject: Possible Netscape source code risks 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 ------------------------------ Date: Fri, 23 Jan 1998 16:31:44 -0500 From: "Steven M. Bellovin" Subject: Filing for divorce on the Internet 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. ------------------------------ Date: Fri, 23 Jan 1998 10:26:03 +0100 From: BROWN Nick Subject: Re: CyberSitter to the rescue (Johnson, RISKS-19.56) 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. ------------------------------ Date: Sat, 24 Jan 1998 11:41:18 PST From: shadow@krypton.rain.com (Leonard Erickson) Subject: Re: CyberSitter to the rescue (Johnson, RISKS-19.56) > ... 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] ------------------------------ Date: Mon, 26 Jan 1998 13:39:00 -0800 From: Ron Crandall Subject: GPS position accuracy and EGPWS 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 ------------------------------ Date: Wed, 21 Jan 1998 17:09:16 -0500 From: CERT Advisory Subject: CERT Advisory CA-98.02 - Vulnerabilities in CDE (Excerpted for RISKS) 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 ------------------------------ Date: Mon, 19 Jan 1998 18:55:46 -0500 (EST) From: Don Gotterbarn Subject: Re: Software Engineering Code of Ethics 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 ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.57 ************************