precedence: bulk Subject: RISKS DIGEST 19.24 RISKS-LIST: Risks-Forum Digest Wednesday 16 July 1997 Volume 19 : Issue 24 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: [BIG BACKLOG. Please be patient.] Errors in California's Megan's Law sex offender CD ROM (Karen Coyle) Website on Spreadsheet Research (Ray Panko) "*sex" County sites blocked (Frank Carey) Jon-Benet Ramsay case "hackers" unmasked: dead battery (Bear R Giles) Credit-card numbers stolen from the Web (Drew Dean) Lewis satellite downlink jammed by car alarm (George Michaelson) Aircraft and Passenger Electronics; FMS Nav Data (Peter B. Ladkin) Mid-air collisions (Hal Lewis) Faulty lavatory smoke detector lawsuit (Frank Carey) High-technology toll road six months late in Ontario (George Swan) "DA computer chief almost loses all to clever sabotage" (James H. Haynes) Re: MD5 weakness and possible consequences (Bear R Giles) DEC Alpha Bug?!? (Gregory F. March) Manual compositing of reuters news on yahoo cocks up (George Michaelson) Calendars (Andrew R Koenig) Follow-up to backhoe attack on cable (Cliff Krieger) Anti-spam technology (Simson L. Garfinkel) List of known macro viruses (Klaus Brunnstein) Web Security & Commerce, Garfinkel with Spafford (PGN) 7th USENIX Security Symposium, Call for Papers (Avi Rubin) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 02 Jul 1997 09:38:27 -0700 From: Karen Coyle Subject: Errors in California's Megan's Law sex offender CD ROM California issued a CD ROM to city and county police departments this week that lists all registered "serious" sex offenders. The CD ROM is available to the public at those departments, where they can look up sex offenders by description, zip code, or other characteristics. However, like many databases, this one has a few problems, as stated in the article in the San Francisco Examiner, 2 Jul 1997: Much of the information about San Francisco's high-risk offenders is out of date. ... "I'm sure that we have lots of people who are dead or have moved away or are incarcerated," said Lt. Tom Bruton of the San Francisco Police department. ... California Attorney General Dan Lungren has acknowledged that the CD-ROM contains outdated or incomplete information on thousands of the sex offenders. About 40 percent of the state's convicted offenders have not registered, he said. " Karen Coyle University of California Library Automation kec@dla.ucop.edu http://www.dla.ucop.edu/~kec [The *San Francisco Chronicle*, 16 Jul 1997, Peninsula Edition, A13, has an article by Charlie Goodyear, in which Lungren acknowledges that 60 to 65 percent of the address and ZIP information is incorrect. Immediately after the CD-ROM was released on 1 July, they realized that juvenile records of four offenders had been included; new databases were created and mailed out. Another revision is now being prepared. Incidentally, the existence of the database is driving some offenders underground. PGN] ------------------------------ Date: Tue, 8 Jul 1997 17:29:14 -1000 From: "Ray Panko" Subject: Website on Spreadsheet Research In recent years, there has been a considerable amount of research on spreadsheets, including error rates. The Spreadsheet Research (SSR) website summarizes data from field audits of more than 300 operational spreadsheets and from experiments involving almost a thousand subjects ranging from spreadsheet novices to long-time spreadsheet professionals. The results are pretty chilling. Every study that has tried to measure spreadsheet error rates has found them and has found them at levels that are deeply disturbing. The URL is: http://www.cba.hawaii.edu/panko/ssr/ Prof. Raymond R. Panko, College of Business Administration, Univ. of Hawaii 2404 Maile Way, Honolulu, HI 96822 (808) 956-5049 Panko@hawaii.edu ------------------------------ Date: Thu, 3 Jul 1997 10:17:35 -0400 From: "Carey, F E (Frank), NCSIO" Subject: "*sex" County sites blocked Three New Jersey counties have found that information they put up on the Internet is being blocked. The Newark (NJ) Star Ledger reports that screening tools (they specifically mention the AOL tool) block access to the Sussex County Fair, Middlesex County College, Essex County College, and the Essex County Clerk's office. It should be obvious what's going on. The string "sex" triggers blocking of these sites. A spokesman for Net Nanny reportedly said that most problems occur when parents rely on the broadest keywords possible, adding that "...some people don't read the manuals." Frank Carey f.e.carey@att.com ------------------------------ Date: Wed, 2 Jul 1997 15:40:17 -0600 (MDT) From: Bear R Giles Subject: Jon-Benet Ramsay case "hackers" unmasked: dead battery (RISKS-19.23) The _Rocky Mountain News_ had an article on 28 Jun 1997 on the unmasking of the "hacker" who invaded the high-security "war room" established by the local Keystones and DA. After fingerprinting the exterior and interior of the computers, our own Inspector Clouseau ruled out the unusually severe weather we had that weekend. Sitting on the edge of tornado alley (and _in_ it, recently), we can have extremely severe weather that causes power glitches, and three other county computers were affected that weekend. No, after exhaustive and undisclosed tests the CBI determined that the computer suffered from... a dead CMOS battery. The newspaper article implied that the police actually had the audacity to name the battery as the _culprit_ in the case, but I refuse to believe that they've extended the Meese Doctrine (that suspects, by definition, are guilty) to inanimate objects. Then again, that would allow them to arrest the garrotte and declare the case closed. The strange twist (as if this case could get any stranger) is that the police yelling "hacker, hacker!" may have encouraged someone to break into the social services computer where data on JonBenet's brother is stored. The second case is still under investigation. Bear Giles bear@indra.com [Also noted by Jonathan Corbet , who commented "Anything can happen when you don't understand your hardware." and by Laura Stinson , who noted that "Excessive paranoia about hackers and inadequate paranoia about systems/hardware failure seems to be the hallmark of most bureaucratic organizations, and often leads to hasty--and inaccurate--causal judgements." PGN] ------------------------------ Date: Fri, 11 Jul 1997 16:31:11 -0700 From: Drew Dean Subject: Credit-card numbers stolen from the Web Over 2,300 customers of Websites ESPN Sportszone and NBA.com [offspring of Starwave] received anonymous e-mail that their credit card numbers had been stolen. Each message said, "You are the victim of a careless abuse of privacy and security. This is one of the worst implementations of security we've seen." -- indicating that the message was from ``an anonymous organization seeking to make the Internet a safe place for the consumer to do business,'' -- and included the last 8 digits of the recipient's credit-card number. However, no fraudulent misuse had been reported. [Source: Web Customers Get Warning on Security, *San Francisco Chronicle*, 11 Jul 1997, C3, datelined Bellevue, WA via Associated Press. PGN Abstracting] I don't know anything else, but I'll conjecture that the problem is not related to cryptography. Anyone want to take a bet on a bad CGI program? Unfortunately, too many people, including the marketing departments of Internet software vendors, tend to confuse cryptography with security. Firewalls are of limited help as we make more and more things work on top of HTTP, which we then allow to pass through the firewall. Of course, really fixing things would cost real money, and take real time, which no one has. The problem with computers isn't that they allow new kinds of fraud (a burglar could just as well go through an old-fashioned file cabinet), but that the fraud can happen on a much larger scale, and much quicker. Drew Dean [Typo on ESPN fixed in archive copy. PGN] ------------------------------ Date: Fri, 4 Jul 1997 16:17:25 +1000 (EST) From: George Michaelson Subject: Lewis satellite downlink jammed by car alarm >From Henry Spencer's *AVWeek&Space* digest on USENET Space news from April 21 *AW&ST*: Strong signal jamming the S-band downlink at the new control center for the Lewis satellite traced to faulty car alarm (!). I liked the imagery, young dude rips off the Camaro, WHAM, suddenly half of the narrowcasting for New Jersey dies... George Michaelson, AAPT, 123 Eagle St, Brisbane QLD 4000 ggm@connect.com.au +61 7 3834 9976 connect.com.au pty/ltd ------------------------------ Date: Sun, 13 Jul 1997 19:25:57 +0200 From: "Peter B. Ladkin" Subject: Aircraft and Passenger Electronics; FMS Nav Data There has been some further discussion recently amongst aviation professionals on possible electromagnetic interference with aircraft systems from passenger electronics [PGN, RISKS-18.47; Ladkin, RISKS-19.48 ]. Concerned RISKS readers might like to read two recent surveys on the possible phenomenon: Albert Helfrick's article, `Avionics and Portable Electronics: Trouble in the Air?', originally published in Avionics News Magazine and available under the Bluecoat Public Reports list at http://bluecoat.eurocontrol.fr under URL http://bluecoat.eurocontrol.fr/reports/Helfrick_96_PED.pdf (Acrobat PDF format, 453K); and a short article I wrote, `Electromagnetic Interference with Aircraft Systems: why worry?' (HTML, 46K), available through my compendium, `Computer-Related Incidents with Commercial Aircraft', section `Do Passenger Electronics Interfere with Aircraft Systems?' at http://www.rvs.uni-bielefeld.de The final report on the Cali accident (Ladkin, RISKS-18.10) cited as one of four `contributing factors' to the accident that the Flight Management System navigational information used a different naming convention from that published in (paper) charts. Recommendations 1 and 7 (of 17) to the FAA address the navigation-database issue, as does Recommendation 3 (of 3) to the International Civil Aviation Organization: `3. Establish a single standard worldwide that provides an [sic] unified criteria for the providers of electronic navigational databases used in Flight Management Systems.' Shawn Coyle of Transport Canada, Safety and Security, has written a working paper in which he identifies a serious problem arising from the lack of standards for industry use in flight management systems of authoritative navigational data. Coyle's paper gives eight examples of circumstances in which there is incompatibility between an FMS's use of navigational data for an approach, and the regulation approach profile itself. Coyle's paper, Aircraft On-Board Navigation Data Integrity - A Serious Problem, is also available on the Bluecoat Public Reports list at URL http://bluecoat.eurocontrol.fr/reports/Coyle_97_Nav_Database.pdf (Acrobat PDF format, 453K). Peter Ladkin ------------------------------ Date: Tue, 01 Jul 1997 21:34:48 -0700 From: hal lewis Subject: Mid-air collisions I posted something on this forum in RISKS-19.11 to the effect that the current air-traffic-control system is illogical, and increases the incidence of mid-air collisions by constricting the available airspace to that which can be easily controlled. In return, I got a moderate level of flame mail, whose common denominator, some making the point with more vigor and ill will than others, was that I was unfair to the FAA. (Some did point out that the FAA is moving in the direction of free flight, but my fifty years of watching the FAA and its predecessor have prevented me from holding my breath.) The current issue of Risk Analysis (April 1997) contains an article by someone who has done a Monte Carlo analysis on the mid-air collision question, and has concluded that the present system increases the collision probability by a factor of four, over random flying. I have not studied the paper, and therefore can't vouch for the methodology, but it is there for those seriously interested in the question. Hal Lewis ------------------------------ Date: Thu, 3 Jul 1997 10:22:30 -0400 From: "Carey, F E (Frank), NCSIO" Subject: Faulty lavatory smoke detector lawsuit The news on 3 Jul 1997 included an account of an Air France cabin attendant who dragged a passenger out of the plane's lavatory with his pants down and, in front of all the passengers, accused him of smoking in the lavatory. The passenger protested that he does not smoke and is responding with a multi-million dollar law suit. A faulty smoke detector is assumed. Frank Carey f.e.carey@att.com ------------------------------ Date: Fri, 11 Jul 1997 16:04:35 -0400 (EDT) From: George Swan 7547 Subject: High-technology toll road six months late in Ontario There is a column in the *Globe and Mail*, 11 Jul 1997, about a new highway completed across the north of Toronto Ontario. Toll roads were unknown here in Ontario. Private industry was invited to tender proposals. The provincial government specified a system for collecting the tolls that would obviate the need for cars to stop to make payments. Frequent travellers would rent a transponder for $2 C per month. Occasional travellers who don't have a transponder would pay a $1 C surcharge per trip in addition to the regular distance fee. Their travel would be tracked by digital cameras that would snap pictures of their license plates. Travellers would get a bill in the mail. Terence Corcoran's article says the toll system has been promised to have been a few weeks away from readiness for six months. So far it has cost twice as much to develop as estimated. Currently travellers are using the road for free. The message for RISKS readers? Just another demon child borne from the courtship of boastful hype and wishful thinking. ------------------------------ Date: Tue, 8 Jul 1997 20:26:52 -0700 From: "James H. Haynes" Subject: "DA computer chief almost loses all to clever sabotage" I'm reading this Associated Press story datelined San Francisco in a paper published in Arkansas. Says Ralph Minow who runs a family support computer system for San Mateo County District Attorney. System crashed in March 1996. Says his assistant Paul Schmidt wanted his job, rigged the evidence to show that Minow deliberately caused the crash. Minow nearly lost his job because of the sabotage; but the perpetrator made enough mistakes that he was detected. Says Schmidt was fired in February, and will be prosecuted if his firing is upheld after a final hearing. His lawyer says Schmidt is being prosecuted for whistle-blowing. ------------------------------ Date: Wed, 2 Jul 1997 18:20:22 -0600 (MDT) From: Bear R Giles Subject: Re: MD5 weakness and possible consequences (Leeming, RISKS-19.16) In RISKS-19.16, Geoffrey Leeming suggests that it would be computationally difficult to find two meaningful pieces of executable code with the same checksum. I disagree, and refer to an old hack as a demonstration of a well-known example. In a more innocent age if you wanted to protect a database against casual alteration (e.g., by buggy programs which directly accessed the data), you would compute a checksum across the entire database. That's a cheap test for non-malicious alteration, but it's too expensive to continually recompute a CRC checksum across a large file. The solution was to reserve two bytes (for a 16-bit CRC) in each record. When the CRC of the entire database is computed this field was set to zero. When a record was edited, the original CRC of the block was computed, then this field was set to the value which forced the CRC for the entire record to remain unchanged. Since the CRC for the block was unchanged, the CRC for the entire file also remained unchanged. (A variant method initialized the field so each record had a known, identical checksum. Then all changes maintained the checksum as an invariant.) This is why standard CRCs aren't good in cryptographic applications. If you can write any data to 16 contiguous bits (or restricted data to a somewhat larger block) you can force the CRC to be any value desired. The 128-bit MD5 hash will obviously require more than 2 bytes... but it shouldn't be too hard to find ways of squirreling small chunks of rewritable data throughout the data. The most obvious approach is static char md5hack[16]; Or you could just use "sloppy" coding practice: static char stealthhack[200] = "hello, world"; You could even sneak the buffer into the code segment: foo (); goto hackaround: /* code is irrelevant, it just takes up space in code segment which will be overwritten later */ for (i = 0; i < 10; i++) j = i; hackaround: bar(); This then becomes a matter of determining an _efficient_ way to set the value of the MD5 (or any) hash function to a desired value. The brute force method (allocate a buffer and write every possible value to it, computing the hash function) is impractical when there are 2^128 to 2^160 possible hash values. But if, for example, you could reduce the problem to 4 problems with 2^32 possible hash values in each... Of course a careful examination of executables or documents will show dead spots or "weird" comments, but who would have the time to run such exhaustive tests on a substantial application or document? Bear Giles bear@indra.com ------------------------------ Date: Wed, 02 Jul 1997 15:14:24 -0400 From: "Gregory F. March" Subject: DEC Alpha Bug?!? So there I am, looking at our trading system and noticing that the price of one particular bond was different on two separate machines. Damn, I think. Must be a bug in the latest release of our software. Quick, do a sum on all the libraries. Nope, they are the same. Executable? Nope, the same. Hmm... Step through the code, hey, look at that! The pow() function is returning different results! So, I wrote a stand alone program. Sure enough, the machine with the latest rev motherboard (one that was just replaced by DEC) is producing bad numbers. Time to try 'dxcalc', DEX's X calculator. Yup. different numbers. How about perl? Yup, different numbers. How about 'bc'? Duh, bc doesn't take floating point powers. Hmm... check libm. Nope, they are the same. Bottom line: DEC will be here shortly. Test your alpha. Try 'pow(1.234567, 7.654321)'. If you don't get 5.017something, you have the same problem. Risks? In our case, could have been a large sum of money. * Gregory F. March * http://www.gfm.net * march@gfm.net * ------------------------------ Date: Tue, 15 Jul 1997 12:19:46 +1000 (EST) From: George Michaelson Subject: Manual compositing of reuters news on yahoo cocks up I track 3 or 4 of the summary pages on http://www.yahoo.com/headlines/ -- which are reworked reuters news info. Several times now, the link and related 1-para summary has hotlinked to completely unrelated stories. Or are they? The last one was a headline on the MIR commander having a heart attack and it linked to a story on Yeltsins sex-life. Just thinking about that one nearly gave *me* palpitations. I suspect that the process is (a) manual (b) mindlessly boring and (c) uses some keyword recognition process, and the person-in-the-loop saw 'russia' in both of them and got the link wrong. ------------------------------ Date: Tue, 15 Jul 1997 11:39:42 -0500 From: ark@attmail.com (Andrew R Koenig) Subject: Calendars I was just browsing through the introductory pages of the pocket-sized calendar book I use. It has blanks for the following information: Name Address Telephone number (home and office) Fax number Religious affiliation Blood type Drug allergies Social security number Driver's license number Automobile registration number Insurance company Credit cards Next of kin At the bottom of the page, it says In event of emergency, please notify ____________ If this diary is found, please return to the owner. Anyone who fills out all that other information had better not lose it... Andrew Koenig ark@research.att.com ------------------------------ Date: Thu, 3 Jul 1997 17:40:48 -0400 From: "Cliff Krieger" Subject: Follow-up to backhoe attack on cable (O'Hearn, RISKS-19.23) In 1973, a similar event happened at Korat Royal Thai Air Force Base and when the US tenant tried to switch to the backup communications cable they found that a large section of it had been stolen some time in the past. The solution was to launch an EC-130 Airborne Command and Control Aircraft (ABCCC) and use it to maintain communications with higher headquarters. The extended risk is that those who do not learn from history are condemned to repeat it. C R Krieger ------------------------------ Date: Mon, 16 Jun 1997 08:49:05 -0800 From: "Simson L. Garfinkel" Subject: Anti-spam technology A little more than a month ago, Vineyard.NET, my ISP, started blocking SMTP connections from computers on the Internet that do not have valid reverse DNS. We did this an an anti-spam measure. A few days after we brought up the new system, spamming dropped dramatically --- more than 75%! We decided to filter against sites that do not have valid reverse DNS because a lot of spammers do not have valid reverse DNS. But it also seems that we have caught up in our filter some legitimate sites that do not have their nameservers properly configured. Below is a list of all of the sites. Interestingly, there are some sites below which are obviously spamming sites (wow.boundless.com, for example). But there are also a lot of legitimate sites as well, like aw.com, www.fda.gov, newshost.nytimes.com. I'm trying to contact the postmasters at these sites to get them to correct their systems. So far, I have sent many messages to the folks at Dow Jones, for instance. Unfortunately, all of those messages have been ignored. So I'm not really sure what to do. I like the anti-spam filter. I don't want to start building an exception list. And it seems that as the Internet gets larger and larger, more and more machines are improperly administered. Perhaps it would be simpler to just block the known spammers. www.fda.gov 150.148.6.1 29 BANYAN.SMTP.IHS.GOV 161.223.220.100 226 mailer.usatoday.com 167.8.29.60 229 portia.teleport.com 192.108.254.5 11 aw.com 192.207.117.2 38 acc 193.227.61.28 11 jupiter.netdepot.com 198.81.231.2 77 wow.boundless.com 199.171.140.20 288 newshost.nytimes.com 199.181.173.226 456 simon.switchboard.com 199.222.0.10 13 charon.valueweb.net 199.227.124.197 58 home.corecom.net 199.237.128.11 77 jupiter.internet-australia.com 203.24.127.2 2 vision.eri.harvard.edu 204.166.91.12 38 aramis.link7.lat.net 204.179.70.11 154 mail2.gp.k12.mi.us 204.39.34.7 154 www.jobson.com 204.5.4.10 2 www.jobson.com 204.5.5.104 33 hermes 204.77.214.122 10 mail-lax-3.pilot.net 205.139.40.17 143 deptvamc2-bh.va.gov 205.183.31.66 238 ns.sprintout.com 205.219.168.10 76 cordoba.shoppingplanet.com 205.254.167.153 1 easyaccess.ieaccess.net 206.112.36.11 39 ns1.digitaldelights.com 206.117.108.254 98 maui.net 206.154.205.1 41 apstech.com 206.242.178.253 1 mailserver.ccipr.com 206.40.70.7 39 netsys.hn 206.48.255.1 77 smtpmail.resortnet.com 206.99.110.1 38 smtp.autobytel.com 207.113.145.22 77 internetmedia.com 207.120.43.133 77 smarti2.smartworld.net 207.121.91.100 18 www.angelfire.com 207.226.241.14 38 mail.macline.net 207.230.18.26 21 WELCOME 207.88.168.5 153 shani.marathon4com.net 208.12.112.31 2 pixelhype.com 208.150.36.215 1 [208.153.0.4] 208.153.0.4 3 nwnet.newsweek.com 208.194.106.7 38 firewall 208.198.116.12 10 listserv.dowjones.com 208.198.167.29 220 t-1net.com 208.21.213.10 34 demie.netsense.net 208.5.234.3 39 lamprey.internetmedia.net 209.25.82.66 30 ns.ultimatew.com 209.36.206.66 38 tripod.com 38.217.84.3 31 wopia.wo.erim.org 38.250.219.10 117 [Incidentally, CSL.sri.com is now filtering out e-mail from sites from which we have been receiving inordinate numbers of spams. This may have some unfortunate consequences, such as RISKS not being able to receive mail from some of you whose ISPs have been deemed less than helpful. Sorry! The situation is really out of hand. I'm getting hundreds of spam messages. PGN] ------------------------------ Date: Thu, 10 Jul 1997 18:30:30 +0200 From: Klaus Brunnstein Subject: List of known macro viruses SUMMARY: Macro Virus List (PC + Macintosh) according to VTC name specification, including (PC) In-The-Wild Indication Vesselin Bontchev @ FSI Klaus Brunnstein, Uni-Hamburg Joern Dierks, VTC Uni-Hamburg Thomas Buck, VTC Uni-Hamburg VTC = Virus Test Center, Status: June 30, 1997 >>> Copyright (c) 1997 University of Hamburg, Germany <<< The number of known macro viruses in June 1997 grew again significantly: with 18 new strains 132 new viruses, growth was significantly reduced as compared to previous months (e.g. 37 new strains with 246 new viruses in May). Only 22 months after Microsoft shipped the first Word macro virus (Concept.A), the 1000th macro virus was reported around June 20, 1997. Strains with fastest growth include Showoff (+15) as well NPAD and CAP (+12) whereas growth of Wazzu (+5) and Concept (+3) is moderate. The "list of known macro viruses", dated June 30, 1997, reports in detail about all known macro-related malware. Here are the essential statistical data: Word + Other = Total (New) -------------------------------------------------------------- Number of Strains 214 + 15 = 229 ( 18) Number of Viruses 1051 + 14 = 1065 (132) Number of Trojans 21 + 7 = 28 ( 0) Number of Generators 10 + 0 = 10 ( 0) Number of Intendeds 22 + 1 = 23 ( 0) Number of Jokes 0 + 1 = 1 ( 0) -------------------------------------------------------------- Remarks: (*)=(viruses+trojans+intendeds+jokes) [list omitted for RISKS] This list is published monthly (normally between the 3rd and 8th of a month) and can be downloaded via FTP from VTCs "new" WWW/FTP site: ftp://agn-www.informatik.uni-hamburg.de/pub/texts/macro/ [Long and short] lists are also available from VTCs "old" ftp site: ftp.informatik.uni-hamburg.de/pub/virus/macro/macrolst.* ------------------------------ Date: Sat, 05 Jul 1997 16:28:43 -0400 From: "Peter G. Neumann" Subject: Web Security & Commerce, Garfinkel with Spafford Web Security & Commerce, Simson Garfinkel with Gene Spafford O'Reilly & Associates, Inc., 1997, $32.95 This is a truly useful book that can help many of you avoid a lot of the risks in Webware -- some of which have been discussed in RISKS, some of which have not. It is intelligently written, timely, informative, accurate, comprehensive, understandable, and a great pleasure to read. It becomes the de facto definitive Web-ster's guide to Web security. ------------------------------ Date: Fri, 27 Jun 1997 10:34:02 -0400 (EDT) From: Avi Rubin Subject: 7th USENIX Security Symposium, Call for Papers (abridged for RISKS) 26-29 January 1998, Marriott Hotel-- San Antonio, Texas Program Chair, Avi Rubin, AT&T Labs - Research Papers due 9 September 1997 Full version of CfP at http://www.usenix.org/sec/cfp.html ------------------------------ 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.24 ************************