Subject: RISKS DIGEST 17.42 RISKS-LIST: Risks-Forum Digest Weds 25 October 1995 Volume 17 : Issue 42 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, etc. ***** Contents: Near-miss Russian atomic sub blow-up (Chen Drori) DejaNews [Deja vu all over again] (Simson L. Garfinkel) The UPS and downs of SCSI disks and embedded interpreters... (Peter da Silva) Comments on AFATDS artillery control software (Eric Remy) Risks of digital video (Craig DeForest) Marketry Redux (Simson L. Garfinkel) Re: Presidential Black Hawk helicopter crash [Name withheld, JdeBP) NCSA FireWallCon '96 (Mich Kabay) Privacy Digests (PGN) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 25 Oct 1995 11:14:17 +0300 From: Chen Drori Subject: Near-miss Russian atomic sub blow-up Sometime during the middle of September, I saw a report on CNN on a barely averted atomic explosion of Russian nuclear submarines: Under the communist regime, the Russian army was supplied with electricity, benzine, gas, raw materials, and all other "necessary" materials that did not require special attention, such as high-tech programs and "exotic" high-cost needs. Since the collapse of communism, though, and the arrival of privatization, the soviet administrative structure was changed, and now the army has to pay for these services out of the military budget. This means that now also the army gets an electric, gas, and what-not bill. I am not clear on this, but it sounds reasonable, and fits well with the story (If anyone knows better, please correct me), but as far as I understand, when in dock, a nuclear submarine relies on outside power to run all its needs, including the reactor cooling systems. Enter our story: In a Russian military base, in the south of Russia, I don't remember the exact site, a Russian base commander was forced to send armed troops to the nearby power plant to force the local power company to turn the juice back on at gunpoint. The power company shut off the military's power supply on account of the huge unpaid bill (I think it was somewhere in the order of $ 2-3 million). The sub's cooling systems failed, and the reactors began to overheat. A nuclear explosion was closely averted. I know there are a few flaws in the story, such as why didn't the subs start cooling on internal power, and why did the company not give any notice before shutting off the current (which would have sent the military screaming at them, but then again they might have thought the power company would never do such a thing), but that's roughly the way it was reported on CNN. Chen Drori, Haetzel 12, PO Box 7219, Yehud, 56214 Israel ceedee@shani.net Tel: 972-3-5360711 Fax: 972-3-5360711 [Relevance? Schmelevance. This item is worth including. It reminds us that many of our problems with technology are outside of the system. PGN] ------------------------------ Date: Tue, 24 Oct 1995 19:09:53 -0400 From: simsong@vineyard.net (Simson L. Garfinkel) Subject: DejaNews [Deja vu all over again] Internet Services Accused of Privacy Violations [This appeared in *The Boston Globe*, 23 Oct 1995.] (C) 1995, Simson L. Garfinkel Simson L. Garfinkel, Globe Correspondent An Internet service that catalogs and indexes messages from electronic bulletin boards is drawing criticism for possibly violating the privacy of the network's users. DejaNews Partners taps into the Usenet global electronic bulletin board network, makes a copy of every message, and stores and indexes them for easy public retrieval. The service has quickly become the fastest and most powerful way for savvy Internet users to find answers to questions, locate lost friends, or even take the pulse of the wired public. Executives at San Antonio-based DejaNews seem perplexed at the near daily messages they receive from computer users who complain that what the company is doing amounts to an invasion of privacy. "When you post to Usenet, it automatically gets propagated to tens of thousands of computers,'' said Steve Madre, president of DejaNews Partners. ``So anybody who posted something to Usenet and then later on has any kind of privacy concerns about it must have seriously misunderstood what they were doing." But it's not just DejaNews' archival retrieval system that has some cybersurfers worried. It is the fact people are unaware their messages are being archived and, perhaps even more insidious, the program's ability to form user profiles of people who post messages -- grouping them by the specific subject matter on which they most frequently correspond. ``No one ever mentioned to me that it was possible to take a different program and run a search on what you've written,'' says Peter Crone, a local graphics designer who reads Usenet through his account with The Internet Access Company, of Bedford. ``Maybe this is as obvious as the sky being blue to techies, but this is the first I've heard of it.'' According to Dejanews, Crone posted three articles to the Usenet between July 27, 1995 and September 2, 1995, to the user groups "rec.arts.startrek.current," "rec.arts.sf.tv" and "rec.arts.sf.starwars." Thus, simply by looking up Crone's name on DejaNews, it is possible for anybody on the Internet to conclude that Crone is a science fiction buff, and that he likes Star Trek and Star Wars. ``It feels a little like a phone tap or something,'' says Crone. The Usenet system is divided into more than 10,000 such special interest ``groups,'' each with their own self-descriptive name, such as "rec.autos.makers.saturn," for Saturn car lovers, and "alt.politics.usa.republican," for devotees of the Republican National Party. Unlike the World Wide Web, which uses the Internet to move pages of information when requested to do so by a user, the Usenet is based upon older technology which actually copies every message to tens of thousands of computers throughout the world. The typical Usenet server has a billion bytes of storage, holding hundreds of thousands of messages at a time. To keep up with the flood of new messages, organizations usually program their Usenet servers to delete old messages after a few weeks. But DejaNews follows a different strategy: instead of deleting old messages, the company archives the messages, becoming a kind of Internet memory bank. The company hopes to support its free service by selling advertising space. Using DejaNews, it is easy to search for every message posted on the net on a particular subject. For example, searching for the name "Warren Buffett" recently returned a list of 20,862 different messages, most from the Usenet group "misc.invest.stocks." You can locate an old friend by searching for all of the messages transmitted over the network that mention the friend's name. But DejaNews also has a sophisticated system for retrieving "author profiles" of the individuals who have posted messages. Using this system, it's easy to retrieve a list of every group in which a particular person has posted a message -- or even the messages themselves. Amy Bruckman, who is a graduate student at the MIT Media Laboratory and sits on the MIT Presidential Advisory Committee on Privacy, says that her concern with DejaNews is that most people using Usenet are not aware of the service's existence. But Usenet has actually been archived for a long time. Many schools, for example, have backup tapes containing Usenet messages dating back many years. Furthermore, says Madere, the National Security Agency and possibly other law enforcement or intelligence organizations has been cross-referencing and indexing Usenet for quite some time. "I know for a fact that they do have a text retrieval database which contains Usenet," says Madere. Creating a searchable index of Usenet " was already done for what people might consider to be sinister purposes," says Madere. "What we have done is made it searchable for useful purposes." But Bruckman says that building comprehensive author profiles represents a further invasion beyond simply allowing searches by keyword. "There are different levels of invasiveness of technology. Being able to record data is one level. Being able to correlate it is another. That's why social security numbers are such a problem -- because they make it easy to correlate large amounts of disparate data about a person." More people might start feeling the same way later this year, when DajaNews starts indexing Usenet groups such as ``talk.abortion,'' in which people exchange political opinions about abortion, and ``alt.sex.incest,'' where people trade stories of sexual abuse. Currently, says Madere, DejaNews does not index any Usenet group whose name begins with the letters alt, talk or soc, although it plans to do so as soon in the near future. DejaNews can be reached at http://dejanews.com/. [Well, I assume all RISKS contributors recognize that every word they utter here gets added to the archives, going back 10+ years. That is certainly an incentive to get your statements correct the first time. PGN] ------------------------------ Date: Wed, 25 Oct 1995 09:03:26 -0500 From: peter@nmti.com (Peter da Silva) Subject: The UPS and downs of SCSI disks and embedded interpreters... [Alan Tignanelli on ATC] > Because of the frequency of the outages, the FAA is considering UPS. I'm horrified. I wouldn't consider leaving a safety-critical computer without some kind of power failure protection. All our servers here are UPS-protected, and the worst that can happen is we might lose a day's work if we have to go back to backups because a disk failed due to an outage. Hell, I've even got an UPS on my personal computer at home. Maybe I'm oversensitized because I'm in the real-time industry. Maybe it really is rocket science... but hey, these guys are *supposed* to be rocket scientists. Surely this is a misunderstanding, and they *were* on an UPS and the UPS went down. [Martin Minow on diagnostic software] > My experience, however, is that modern SCSI disks are extremely reliable, > and there isn't much cost/benefit in doing this: remember, the personal > computer user community does not -- and should and should not -- need to > know about technical details within their computer systems. Here, a > comparison with modern computer-infested automobile control systems seems > relevant: how often do you want to examine the engine logs? Whenever I take the car to the garage, I would hope the logs would be examined. Since a laptop isn't taken to the mechanic, the operating system should be performing this job for me. [and Charley Wertz on trojan horses] > Am I missing something? I don't think so. > Does anyone have some good solutions? Designing languages so they're inherently safe. For example, if there is no "open file" primitive in the language, it can't be used to modify files. Sun has a *separate* development going on based on a language called Tcl. The original version of Tcl had no file I/O of note, it was purely an extension language. I wrote some file I/O routines, and they have been pretty much incorporated straight into the language... but they're not integral to the operation of the interpreter. There's a variant called Safe Tcl that's dropped back to the extension language model. See also: http://minsky.med.virginia.edu/sdm7g/Projects/Python/safe-tcl And to learn how Tcl can be used in a product, look at: http://psg.com/~joem/CmdWrite.html There's also a Tcl web browser: http://pastime.anu.edu.au/SurfIt/ I have no idea how good SurfIt is... I just ran into it while browsing the web looking for URLs for this article. ------------------------------ Date: Tue, 24 Oct 1995 17:15:35 -0400 From: edremy@inforamp.net (Eric Remy) Subject: Comments on AFATDS artillery control software (Graf, RISKS-17.41) David identifies two main risks, both of which I feel are overstated > AFATDS could give a "fragger" the chance to > do a lot more damage than he/she could do just using a grenade or gun. Very few safeguards exist today against a determined "fragger". In my former job as a tank commander, I could have easily killed hundreds of people while on a live fire range before my crew could have stopped me. The only real safeguard you can take for artillery is to have multiple people work out the solution: this is already done in peacetime on live-fire ranges. >Second, there are the problems of unexpected software bugs which could >misdirect fire or even abend the entire system. Given that the consequences >of either misdirected artillery barrages or losing artillery support >altogether could literally be a matter of life or death. Bugs are always a problem, however, all artillery units currently use digital fire control computers. The software has been well tested, but I doubt that it's bug free. The US Army in general is very good about having backup systems. Currently, artillery units are equipped with the BUCS- BackUp Computer System, which looks much like a modified HP calculator. Slower and harder to use, but still there. In addition, artillery folks are trained in pure manual tables as well, although I don't know how much they practice with them. (For those who are curious, a lot of the live fire exercises Armor units practice on are in "degraded mode", simulating failure of fire control computers, stabilization systems, rangefinders, etc.. Very smart, IMHO) Assuming this is the software that I've read about elsewhere, I'd push heavily for this to be fielded ASAP. Why? Mainly because it has links into positioning equipment such as GPS and inertial systems. Getting lost in the desert/woods is an _enormous_ problem, and trying to direct artillery fire when either the observer or the arty unit is in the wrong place invites disaster. I'd feel a lot more comfortable if everyone knows where they are, even with occasional software bugs- those can at least be fixed ahead of time. Eric Remy ------------------------------ Date: 24 Oct 1995 22:18:39 GMT From: zowie@banneker.stanford.edu (Craig DeForest) Subject: Risks of digital video (Markowitz, Re: RISKS-17.41) Sidney Markowitz said: : ... I have to wonder if [the recent story of a female exec's video : email blunder] is ... urban myth. [Technical objections deleted] Mr. Markowitz might be surprised at what can be done with computers made by his own company. Connectix makes a $99 b/w video camera (the QuickCam) for MacIntosh. It plugs into the serial port of a Mac, needs no additional hardware, and comes with a large number of support applications. It can be used to capture video or still images for attachment to mime encoded email, or (with Columbia University's "CU See Me") to videoconference over a 14kb slip or ppp connection. I use mine on a Powerbook 165c. In fact, a similar event occurred to a friend of mine, the webmaster at http://www.cliq.com. Cliq is located in one of the bedrooms of a co-operative house one block from the Haight/Ashbury intersection in San Francisco, and for a time they ran the "HaightCam", serving live digital stills of Haight/Ashbury taken with a QuickCam on a Mac iici. My friend, while prototyping the HaightCam server, left it pointed out from his desk. His bed was in the background. One Sunday morning I was browsing the site, and was surprised to find out more than I cared to about his success at romance. Shortly thereafter, the HaightCam was permanently mounted where it would point out over the street. The point is that, with cheap digital input devices and powerful data broadcast techniques available to everyone, one never knows when one is in private and when one's likeness is being broadcast. Video cameras are not new; the coming ubiquity of live broadcasting digital cameras is. (Meanwhile, ftp://banneker.stanford.edu/pub/incoming/mdi.gif contains a live image of the SOHO/MDI instrument control room at Goddard Space Flight Center, where I'll be on Monday 10/30/95. For information about the SOHO spacecraft, check http://sohowww.nascom.nasa.gov.) ------------------------------ Date: Tue, 24 Oct 1995 19:09:57 -0400 From: simsong@vineyard.net (Simson L. Garfinkel) Subject: Marketry Redux Last week, I spoke with Norm Swent, president of Marketry, a Seattle-based direct mail firm. Swent says that his company is not going ahead with the e-mail target marketing because there is no way to opt out. Marketry did not collect the e-mail addresses incidentally. An individual did. And he is now trying to find somebody else to pay for his services. By the way --- I've been getting 10 or so advertisements in my mailbox each week. I guess other people have been as well. The funny thing is, the return-addresses never work properly. They always want me to send a check to some PO box somewhere. ------------------------------ Date: Tue, 24 Oct 1995 12:22:31 -0700 From: [Name withheld by request] Subject: Re: Presidential Black Hawk helicopter crash I've been following the Black Hawk crash thread with interest. I live only a couple of miles from the crash site, and this was really big in our local news. This is not a hoax or urban legend, the crash did occur. [DISCLAIMER.... I have no first hand information pertaining to the crash, however I will summarize the points made in an ongoing series of articles published in our local newspaper, the Maryland Independent. This series ran a year or so ago, and my memory may be somewhat faulty. Again, I'm only summarizing published newspaper reports...] An amateur archeologist, (Mr. Owens?) was performing exploration of indian ruins in a remote area in southern Maryland along the Potomac river near Harry Diamond Research Labs (A highly secure government facility), and he observed the crash. This individual observed the helicopter hovering normally just above the tree tops, and then suddenly go down. He was the first individual at the crash scene (within several minutes of the incident), and he stated the there were serious cut injuries to the one of the pilots legs, but that the wound had little or no bleeding, and their skin had a yellowish cast as if burned, but that there had been no fire. He also stated that none of the injuries he noted looked as if they would have been fatal in the short time it took him to reach the crash scene. Charles County deputies and rescue squad individuals responded and secured the site, taking photographs. Some time later, military personnel arrived and confiscated all evidence and requested that all civilian personnel leave the accident area. As background, the military allegedly did EMP (Electromagnetic Pulse) testing at the Patuxent River Naval Air Station in nearby St. Mary's county Maryland in the early 80's. This testing was supposedly moved but moved to a location in Woodbridge, Virginia after complaints that this type of testing was very risky, because the Calvert Cliffs Nuclear Powerplant is only a couple of miles from PAX river NAS, and concerns of EMI possibly affecting the plants electronic control systems were realized. (How's that for a risk?) After supposedly moving to the Woodbridge facility, the government began receiving pressure to relocate the facility from Woodbridge, because civilian aircraft on approach to National Airport (just up the Potomac river from Woodbridge) were having EMI problems with navigation equipment. It is believed that this project was then moved across the Potomac river to Harry Diamond Labs, close to the accident scene. (HD lab has very tight physical security, and is in a relatively rural area) Historically, HD labs has been involved in high security defense related research projects. The military currently states claims that this project has now been relocated to New Mexico, and will make no comment on the conjecture that it ever was ever based at Diamond Labs. The military officially reported that a pin in the helicopter had been installed backwards, and that was the cause of the crash. However, when interviewed, the helicopter mechanic stated the pin was not installed incorrectly, and his supervisor also stated that he was present during the pin installation and it was performed correctly. Other helicopter mechanical experts interviewed stated that if this pin was installed "backwards", that failure should have occurred on the ground during the warm up period within a minute or two of start up. The Black Hawk had supposedly been aloft for more than 20 minutes, and had flown across the Potomac river, at least 7 miles from it's base. After Mr Owens began questioning official reports blaming the pin installation as the cause of the crash, the military supposedly became quite uncooperative with Mr. Owens and others interested in the crash. Other points noted in the article. No disciplinary action occurred to the helicopter mechanic who supposedly incorrectly installed the pin, causing loss of life and aircraft. In a case where loss of life occurs due to negligence, some type of disciplinary action usually occurs. The yellowish cast of the pilots skin and lack of any blood due to internal coagulation was reported to be consistent with severe microwave burns. The attitude of the military pertaining to crash details changed considerably when the issue of EMP testing as a possible cause of the crash was raised by Mr. Owens and the families of the individuals lost in the crash. ---------------------------------------------------------------------------- Date: Sat, 21 Oct 1995 19:14:03 +0100 From: JdeBP@jba.co.uk Subject: Re: Presidential Black Hawk helicopter crash (Coley, RISKS-17.xx) Although many others have brought several aspects of this report into question, with the suspicion that it is nothing more than conspiracy theorising with no substantial base whatsoever, one issue has not been addressed. To me, it appears to be the most obvious one : How come an *archaeologist*, only present at the scene of the accident by chance, seems to know so much about the design of military aircraft and the investigative procedures used in aircraft crashes ? In the true spirit of conspiracy theory, should we not assume that since Mr Owens (assuming that that such a person exists) was so conveniently near to hand at the time of the accident that he is in some way related to it ? Could it not be that he is in the employ of the people that *really* caused the crash, and is masquerading as an innocent bystander who embarks upon a baseless but nevertheless high-profile crusade about Army helicopters and EMI, in order to distract attention away from the real cause ? ------------------------------ Date: 25 Oct 95 11:41:33 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: NCSA FireWallCon '96 Here is the short form of the current program and registration information for FireWallCon '96. For the complete and most up-to-date version of this program, send any message via e-mail to the NCSA infobot using address: firewallcon@ncsa.com . FireWallCon '96 Stouffer Hotel, Arlington, VA Jan 25-26, 1996 CONFERENCE OVERVIEW The Firewall and Internet Security Conference (FireWallCon '96) is NCSA's first international conference dedicated to the exchange of ideas, policies, and methodologies for implementing practical Internet security. FireWallCon '96 will bring together international experts to address the key issues in this rapidly evolving field. We will also provide a forum where attendees can exchange in-depth technical information with the major Internet Security/Firewall product developers. NCSA Firewall and Internet Security Conference Program (Abbreviated) Thursday, Jan 25: 9:00 - 10:30 The Electronic Intrusion Threat on the Internet Moderator: Ted Phillips/Booz-Allen Hamilton David Slade, AT&T Steve Branigan, Bellcore 11:15 - 12:00 Identifying System Vulnerabilities Christopher Klaus, ISS 12:00 - 1:30 Lunch with Keynote TBD 1:45 - 2:30 Introduction to Internet/Firewalls William Hugh Murray, Deloitte-Touche 3:00 - 3:45 Establishing an Internet Security Policy Stephen Cobb, NCSA 4:00 - 4:45 Evaluating Firewalls Tammy Mannarino, National Security Agency 5:00 - Reception Friday, Jan 26: 9:00 - 10:30 Establishing an Emergency Response Team Moderator: Alan Fedeli, Manager, IBM CERT 11:15 - 12:00 Viruses and Other Malicious Software on the Internet Dr. Richard Ford, NCSA 12:00 - 1:30 Lunch with Keynote TBD 1:45 - 2:30 Security on the World Wide Web Larry J. Hughes, Jr., Indiana University 3:00 - 3:45 Connecting to the Net Securely Without UNIX Moderator: Charles Rutstein, Price Waterhouse 4:00 - 4:45 Social Engineering: The Non-Technical Threat Ira Winkler, SAIC VENDOR TRACKS In addition to the technical track, there will be two parallel vendor tracks. Firewall and Internet security vendors will be afforded the opportunity to make technical product presentations. We anticipate having 20 such vendor presentations. Specific information about these presentations is not yet available. Up-to-date information about the entire program may be obtained by sending any e-mail message to: firewallcon@ncsa.com ... [details omitted for posting on RISKS] ... [TNX! PGN] For more information about NCSA conferences, courses and services: WWW: http://www.ncsa.com CompuServe: GO NCSA E-mail: info@ncsa.com (send blank message) M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: 24 October 1995 Subject: Privacy Digests Periodically I will remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern. * The PRIVACY Forum is run by Lauren Weinstein. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the first text in the BODY of a message to: privacy-request@vortex.com You will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". Information and materials relating to the PRIVACY Forum may also be obtained via ftp to "ftp.vortex.com", gopher at "gopher.vortex.com", and World Wide Web via: "http://www.vortex.com". * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available. PGN ------------------------------ Date: 6 September 1995 (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) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] 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. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://unix.sri.com/risks [if your browser accepts URLs.] ------------------------------ End of RISKS-FORUM Digest 17.42 ************************