precedence: bulk Subject: Risks Digest 22.65 RISKS-LIST: Risks-Forum Digest Friday 28 March 2003 Volume 22 : Issue 65 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. ***** This issue is archived at http://catless.ncl.ac.uk/Risks/22.65.html and by anonymous ftp at ftp.sri.com, cd risks . Contents: Autotote betting scam sentencing (PGN) Patriot software again a concern? (James Paul) Surveillance Nation (Monty Solomon) U.S. lifts FBI criminal database checks (Peets) Text message disables Siemens mobile phones (Derek K. Miller) Wireless mushrooms (Brian H. Seborg) Failure of aircraft electronic displays at a critical moment (Peter B. Ladkin) A320 incident partly due to computer failure (Peter B. Ladkin) Paper is good (David Magda) FTC's National Telemarketing "Do Not Call" Web Site to Launch 1 Jul (CDT Info) Transient Microsoft Passport security vulnerability (James Van Bokkelen) Re: Traffic lights don't work in the snow (Ryan O'Connell) Re: Beware the spelling checker (Crispin Cowan) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 21 Mar 2003 11:08:57 PST From: "Peter G. Neumann" Subject: Autotote betting scam sentencing Auto-tote that charge, and lift that trail, Get a little bunk-o, and you land in jail. [Apologies to "Old Man River"] In RISKS-22.33 and 22.38 through 22.40, we discussed the case of the former Autotote programmer who hacked the Catskill NY off-track horse-race betting system (which had a very weak audit trail), resulting in a rigged $3 million winning Breeders' Cup Pick Six bet, plus other previous scams, on which his two Drexel frat buddies collected the winnings. The sentences have now been handed down. Programmer Chris Harn was given the minimum possible jail time -- only a year and a day instead of "up to seven years" -- because he "helped" the authorities; his frat buddies were given two- and three-year terms. [Source: *San Francisco Chronicle* item, 21 March 2003] I suppose one of the tabloids might find a cute headline such as Fat-cat frat rat begat rat-a-tat automat reformat, sat pat. Splat! ------------------------------ Date: Wed, 26 Mar 2003 01:58:13 -0500 (EST) From: james.paul@mail.house.gov Subject: Patriot software again a concern? "For the second time in as many days, a U.S. Patriot missile defense battery has apparently locked its sights on an allied fighter plane, raising concern about a potentially serious glitch in the system's targeting software." A Patriot system about 30 miles south of Najaf in Iraq apparently locked on to an Air Force F-16 fighter on 24 Mar, and prepared to fire. The F-16 responded by firing a high-speed anti-radiation HARM missile at the battery, destroying its radar dish. This came a day after a Patriot missile shot down a British Royal Air Force Tornado GR4 fighter near the Kuwaiti border, killing both crew members. The British fliers were the first known friendly fire casualties of the war in Iraq. [There was discussion about whether to blame the Patriot software or the system operators, although evidence seems to favor the former.] [Source: Jonathan Weisman, *The Washington Post*, 25 Mar 2003; PGN-ed] http://www.washingtonpost.com/wp-dyn/articles/A29390-2003Mar25.html [The Patriot of course had a checkered role in the 1991 Persian Gulf War, with initial reports of great success, followed by official reports that it was only about 10% successful. But after three major upgrades, it is now thought to be much better, having knocked out 6 of 14 Iraqi missiles. PGN] [Incidentally, NBC on 24 Mar 2003 had an item on self-inflicted damage, noting that in the Vietnam War, 24% of U.S. fatalities were due to friendly fire. I have heard reports that it was even higher in the first Gulf War. That is truly astounding! PGN] ------------------------------ Date: Wed, 19 Mar 2003 17:30:58 -0500 From: "monty solomon" Subject: Surveillance Nation Surveillance Nation [excerpt for RISKS] Dan Farmer & Charles C. Mann, MIT *Technology Review*, cover story, Apr 2003 Webcams, tracking devices, and interlinked databases are leading to the elimination of unmonitored public space. Are we prepared for the consequences of the intelligence-gathering network we're unintentionally building? Route 9 is an old two-lane highway that cuts across Massachusetts from Boston in the east to Pittsfield in the west. Near the small city of Northampton, the highway crosses the wide Connecticut River. The Calvin Coolidge Memorial Bridge, named after the president who once served as Northampton's mayor, is a major regional traffic link. When the state began a long-delayed and still-ongoing reconstruction of the bridge in the summer of 2001, traffic jams stretched for kilometers into the bucolic New England countryside. In a project aimed at alleviating drivers' frustration, the University of Massachusetts Transportation Center, located in nearby Amherst, installed eight shoe-size digital surveillance cameras along the roads leading to the bridge. Six are mounted on utility poles and the roofs of local businesses. Made by Axis Communications in Sweden, they are connected to dial-up modems and transmit images of the roadway before them to a Web page, which commuters can check for congestion before tackling the road. According to Dan Dulaski, the system's technical manager, running the entire webcam system-power, phone, and Internet fees-costs just $600 a month. The other two cameras in the Coolidge Bridge project are a little less routine. Built by Computer Recognition Systems in Wokingham, England, with high-quality lenses and fast shutter speeds (1/10,000 second), they are designed to photograph every car and truck that passes by. Located eight kilometers apart, at the ends of the zone of maximum traffic congestion, the two cameras send vehicle images to attached computers, which use special character-recognition software to decipher vehicle license plates. The license data go to a server at the company's U.S. office in Cambridge, MA, about 130 kilometers away. As each license plate passes the second camera, the server ascertains the time difference between the two readings. The average of the travel durations of all successfully matched vehicles defines the likely travel time for crossing the bridge at any given moment, and that information is posted on the traffic watch Web page. To local residents, the traffic data are helpful, even vital: police use the information to plan emergency routes. But as the computers calculate traffic flow, they are also making a record of all cars that cross the bridge-when they do so, their average speed, and (depending on lighting and weather conditions) how many people are in each car. http://www.technologyreview.com/articles/farmer0403.asp ------------------------------ Date: Wed, 26 Mar 2003 18:15:30 +1100 (EST) From: Peets Subject: U.S. lifts FBI criminal database checks The Justice Department has lifted a requirement that is supposed to ensure the accuracy and timeliness of information about criminals and crime victims before it is added to the National Crime Information Center database, which includes data about terrorists, fugitives, warrants, people missing, gang members, and stolen vehicles, guns, and boats. Records are queried increasingly by the nation's law enforcement agencies to help decide whether to monitor, detain or arrest someone. The records are [supposedly] inaccessible to the public, and police have been prosecuted in U.S. courts for misusing the system to find, for example, personal information about girlfriends or former spouses. [RISKS has noted at least two such cases resulting in deaths of the identified persons.] Officials said the change, which immediately drew criticism from civil-liberties advocates, is necessary to ensure investigators have access to information that can't be confirmed but could take on new significance later, FBI spokesman Paul Bresson said. [...] Critics have noted complaints for years about wrong information in the computer files that disrupted the lives of innocent citizens, and the FBI has acknowledged problems. In one case, a Phoenix resident was arrested for minor traffic violations that had been quashed weeks earlier; in another, a civilian was misidentified as a Navy deserter. [Source: Ted Bridis, AP, 25 Mar 2003; PGN-ed] http://news.yahoo.com/news ?tmpl=story2&cid=542&u=/ap/20030325/ap_on_go_ca_st_pe/fbi_database_4&printer=1 ------------------------------ Date: Wed, 19 Mar 2003 10:15:19 -0800 From: "Derek K. Miller" Subject: Text message disables Siemens mobile phones MacInTouch.com relays a CNET News.com report by Ben Charny that a particular text message can disable cell phones manufactured by Siemens. The e-mails contain a single word, taken from the phone's language menu, surrounded by quote marks and preceded by an asterisk, such as "*English" or "*Deutsch", Siemens said. Opening the short-text message on a Siemens 35-series cell completely disables it [according to Siemens spokesman Jacob Rice]. Siemens 45-series phones are less affected and can be resuscitated after about two minutes of work. Both phones are sold only in Europe. The phones are not the victim of a denial of service attack, as suggested by some participating in an e-mail string on Bugtraq, a popular security e-mail list. "It's just not possible," Rice said. [Source: news.com, 18 Mar 2003] http://news.com.com/2100-1039-993197.html?tag=macintouch Derek K. Miller dkmiller@pobox.com http://www.penmachine.com Penmachine Media Company, Vancouver, Canada ------------------------------ Date: Thu, 20 Mar 2003 14:52:47 -0500 From: "brian-h seborg" Subject: Wireless mushrooms Many articles have covered wireless security issues from a technical perspective including the weaknesses in WEP, the fixes to WEP (fast-packet keying), and recommendations for securing a wireless network (802.1x, suppress SSID broadcast, etc.), and I suspect that we in the technical community have a pretty clear understanding that tried and true network security solutions like SSL, SSH, firewalls, IPSec, two-factor authentication, etc. can be brought to bear to secure wireless networks in the same way we have used them to secure Internet and dial-up connections for years. The question is, do non-technical users have any knowledge of these things? My own experience is that the answer is "no." ISPs, especially those offering DSL and high-speed cable modems aren't doing much if anything to make up for this deficit even though they are now delivering wireless routers to customer's homes. I have noticed that in the last month three more access points have popped up in my neighborhood. Of the five I can see, only one has WEP turned on and all are broadcasting their SSIDs (making them visible to even a novice). As I drive around in my car, I can easily connect to four of these access points. Further, when I checked to see if I can connect to the default administrative port, I can do so on all but the WEP protected one, and on three, I see they have not reset the default admin password, meaning I could, if I were a bad guy, reconfigure their router either rendering it useless (until they re-initialize it), or opening it to the Internet. The fact that insecure access points are springing up like mushrooms makes it likely that we will begin to see a rash of hacked home users unless the high-speed Internet providers wake up and begin providing guidance to their customers about how to properly secure their wireless routers. In the case where Internet providers are supplying the wireless gear, it would seem prudent that they would supply each device with a default safe configuration (random SSID, SSID broadcast suppressed, random admin username, random admin password, etc.). Unfortunately, like usual, appropriate measures are unlikely to be taken until security breaches begin to get noticed and customers begin to complain. In the meantime, as good neighbors, we might consider performing a high-tech neighborhood watch informing neighbors that their home networks are insecure. :-) ------------------------------ Date: Thu, 20 Mar 2003 08:52:17 +0100 From: "Peter B. Ladkin" Subject: Failure of aircraft electronic displays at a critical moment David Learmount reports in Flight International, 11-17 Mar 2003, p12, on the loss of attitude information on the electronic attitude direction indicators (EADI) in a temporary loss-of-control incident due to icing with an Embraer Brasilia commuter turboprop operated by Comair. The incident happened on 19 Mar 2001, and was investigated by the US National Transportation Safety Board. I have been unable to reach the FAA Incident Database to obtain the original documents (it refuses my connection). The aircraft was cruising at 17,000 ft when it encountered icing conditions. It oscillated violently in roll (110 degrees left, 130 degrees right, then a 360 degree roll to the right -yes, that's a full rotation) and pitched 60 degrees nose down. During this manoeuvre, the EADIs, which present crucial information to the pilots, "blacked out". The attitude indicator gives perhaps the most crucial control information available to pilots in instrument flight conditions. They recovered at 10,000 ft altitude when the aircraft emerged into visual flight conditions below the cloud. They pulled 3.6g to recover from the descent, itself a hairy manoeuvre. "In subsequent test of the EADIs according to the production test requirements (PTR), the first officer's display was found to have an intermittent rate failure. However, the PTR does not test the equipment against its specified maximum performance in roll and pitch rate, not reacting in the icing incident until almost all the violent roll oscillations had occurred." "The NTSB reports that the EADIs blacked out well before the specified performance limits had been reached,and benchtests in the performance area between the standard PTR criteria and specified performance limits caused both instruments to malfunction." The NTSB apparently suggests that all Rockwell-Collins AHC-85 EADIs have been inadequately tested following manufacture and after maintenance. Rockwell-Collins apparently says that it did not carry out tests beyond PTR, and that the unit's performance at limits could be inferred from the results of the tests to PTR. One cannot, and should not, conclude, however, that use of these electronic devices has led to new types of failures. Traditional mechanical gyroscopes would likely have tumbled in these manoeuvres, and the pilots would have thus been no better off. The issue that this incident highlights concerns the discrepancy between expected performance (represented by the PTRs and the "limits") and actual performance. This is a specification and testing issue. Peter Ladkin, University of Bielefeld, Germany, http://www.rvs.uni-bielefeld.de [Typo corrected in archive copy. "not reaching" --> "not reacting"] ------------------------------ Date: Thu, 20 Mar 2003 18:03:17 +0100 From: "Peter B. Ladkin" Subject: A320 incident partly due to computer failure John Sampson pointed out to me a computer-related incident to an A320. On 21 May 1998, a Leisure International Airways A320 overran the runway at Ibiza Airport in the Balearic Islands. The damage was minor (broken nosewheel and consequent underbelly damage, dirt and stones ingestion in the engines, etc), and there were no serious injuries, so the incident probably does not rate as an accident. The accident report is not long and a PDF version may be found at http://www.mfom.es/ciaiac/publicaciones/informes/1998/1998_019_A.pdf Braking on landing is normally automatic, controlled by the Brake and Steering Control Unit (BCSU) computer. The BCSU is selected "on" during approach, by pressing the "A/SKID & N/W STRG" (Antiskid and nosewheel steering) button on the front panel in the cockpit. The BCSU has two identical channels, active ("hot") and standby, and there is a command (COM) and monitor (MON) function of the BCSU. MON checks COM for agreement before output is sent. Upon detection of a disagreement, a "disagree" condition is logged in the BCSU as well as sent to the Centralised Fault Data Interface Unit (CFDIU). Suppose a fault develops and is detected in the hot channel. If hot and standby channels are both functioning, the system then transfers control to standby, which becomes hot and operates non-redundantly (that is, the faulty channel remains permanently cold). If standby is cold, hot remains active, control is not transferred, and one lives with whatever functions are still provided by the faulty hot channel. The BCSU performs a functional test on selection of Landing Gear Down, opening the Normal Selector Valve, which allows pressure from the Green hydraulic system to reach the four servo valves of the Normal system (Normal Servo Valves, NSVs). The BCSU then sends current momentarily to the NSVs and monitors the pressure rise. It then closes the NSVs, closes Normal Selector Valve, and then opens the NSVs again to release the pressure. This will have happened on the incident flight, says the report. If the Normal braking system is inoperative, Alternate braking is made available by a spring-biased changeover valve (Automatic Selector Valve) which allows pressure from the Yellow hydraulic system to the Alternate braking system. Alternate braking is achieved through foot pedal pressure, transmitted hydraulically along a low-pressure line and ported through a Brake Dual Distribution Valve (BDDV) and a Dual Shuttle Valve to the Alternate servos on the brakes (these are separate devices from the NSVs). Antiskid is controlled by the BCSU, if still operative. There is also a Parking Brake, operating off the Yellow system, backed up by a Brake Accumulator. Operating the Parking Brake handle applies unmodulated Yellow system hydraulic pressure (but reduced) to the brakes via the Parking Brake Valve. Or so it all says here. One problem is as follows. The status of the BCSU switch is sampled every 20 msec asynchronously by the COM and MON functions. It is possible that a short switch operation, from 20 ms to 50 ms, could be detected by one function and not by the other, causing a "disagree" fault in one, or indeed in both, channels of the BCSU. The analysis concludes that this indeed happened. The crew saw the "BRAKES BSCU Ch 2 FAULT" message on the Electronic Centralised Aircraft Monitoring (ECAM) display on selection of the BCSU. The message is listed in the Operating Manual as for "Crew Awareness" and there is no corresponding procedure. It turns out that the crew could have reset the BCSU but this info is not in the Abnormal and Emergency Procedures section of the Ops Manual, but in the Supplementary Techniques section, where it commences with the conditional "In case of braking /steering difficulty..." which they did not have because they were still in the air. What will have then happened is that the hot channel, Channel 2, will have relinquished control to the standby, Channel 1, which will have logged the same fault, but cannot relinquish control since it is operating without a standby. On sensing touchdown ("Weight on Wheels"), four seconds after the spoiler deployment signal, the Autobrake function of the BCSU calls the command function to apply current to open the Normal Selector Valve. The COM/MON disagreement fault becomes a failure; the Normal Selector Valve is not opened, the Autobrake function is lost and the Normal braking system is left inoperative. This is recorded in the CFDIU as a failure in the NSVs (although the actual failure was upstream), which is sent to the ECAM as a "BRAKES AUTO BRK FAULT" message, which is inhibited from display during landing until engine shut down, but is recorded for post-flight replay. So the crew never saw it. The Alternate system was inhibited due to moisture contamination of the BDDV, which it was presumed had turned to ice during flight and inhibited operation of the BDDV. This course of events was confirmed by subsequent testing. In principle, the crew could have used the parking brake, but they had not been so trained. It says in the operating manual that operating the parking brake deactivates the other braking systems. At the end of the overrun area, there is a sea wall and the Mediterranean Ocean. Rather than risk taking a swim, the captain swerved the aircraft from side to side to lose momentum through scrubbing the tires, and then turned it finally 90 degrees away and bumped over the grass and into a low bank "to remain within the aerodrome boundary". The report describes the ride thereto as "quite rough". BCSU software Release 7 was on board; Release 8 provides a fix for the sensing discrepancy condition involved in this incident; Release 9 was released after in-service experience with Release 8. I don't know what release is current. Peter Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de ------------------------------ Date: Sun, 23 Mar 2003 12:55:28 -0500 From: David Magda Subject: Paper is good As we all (should) know, paper is still a useful thing to have around. A weblog entry from [1]: --- entry --- Sat, 22 Mar 2003 Books in Print Wouldn't Fit An odd thing happened on my way to buy a book at my local Barnes and Noble. [Yes, yes, before you go and point it out, any story that starts out this way is almost certainly my fault.] Me: Can you tell me who the author of ______ is? Retailer: I can't. Me: Well, can you look it up? Retailer: I can't. Our computers are down. Me: Ah. Well, can I take a gander at your Books in Print. Retailer: [Smirks] We don't have a list of all the books in print. We wouldn't be able to fit it in the store. Me: In fact you would. We had these great big volumes and then later microfiche when I worked in a bookstore a number of years back. Retailer: Do you know how many books that would be? Me: Lots, I do believe you. But the fact remains that Books in Print is indeed a real thing. Retailer: Well, we don't have it. We have computers instead. Me: Apparently not. [Only ever so slightly paraphrased.] --- entry --- Book in Print(tm) can be found online at [2]: assuming that your computer is up, the 'Net is working, and their computer is up. :> You need an account to search their online catalogue. A paper version is described at [3]. [1] http://www.raelity.org/archives/society/literature/books_in_print_wouldnt_fit.html [2] http://www.booksinprint.com/bip/ [3] http://www.bowker.com/bowkerweb/catalog2001/bibtoc.htm David Magda ... Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI ------------------------------ Date: Wed, 26 Mar 2003 15:06:50 -0500 From: CDT Info Subject: FTC's National Telemarketing "Do Not Call" Web Site to Launch 1 Jul [via Monty Solomon] The Federal Trade Commission has announced that the Web site allowing consumers to put their telephone numbers on the national registry to stop telemarketing calls will launch in July. The FTC will also have a toll free number to call. The FTC expects overwhelming demand for the project and is therefore rolling out the toll free number beginning on the west coast and heading east throughout the summer. March 26, 2003 The FTC The National "Do Not Call" Registry Page http://www.ftc.gov/bcp/conline/edcams/donotcall/index.html [NOTE ADDED 22 Jul 2009: BROKEN LINK. TRY THIS: http://www.answerconnect.com/articles/the-national-do-not-call-registry ] Comments of CDT and others to FTC supporting "Do Not Call" list [pdf] March 28, 2002 http://www.cdt.org/privacy/020328cpg-dnc-comments.pdf CDT comments to FCC on "Do Not Call" December 9, 2002 http://www.cdt.org/privacy/021209cdt.shtml http://www.cdt.org/mailman/listinfo/cdt-announcements ------------------------------ Date: Wed, 19 Mar 2003 16:05:18 -0500 From: "James Van Bokkelen" Subject: Transient Microsoft Passport security vulnerability When a laptop arrived last week with a sacrificial Windows XP Home Edition installed on it, we combined curiosity with a testing opportunity, and analyzed its network traffic with our NetIntercept tool. After using UDP-based protocols to locate resources, and HTTP and HTTP over SSL to register itself, the WinXP installer asked if we wanted to create a .NET Passport account. We agreed. After an initial exchange with host nexus.passport.com using HTTP over SSL, subsequent HTTP connections used normal HTTP on port 80. We were quite surprised by several POST commands to register.msnia.passport.net. Each contained plaintext answers to the previous screen's questions. All the critical data necessary to hijack the .NET passport was exposed: name, birthday, ZIP, gender, occupation, password and secret question/answer. A more detailed analysis can be found at http://www.sandstorm.net/passport This took place on the morning of 14 Mar 2003. Microsoft was informed as soon as we made our way through the obfuscation protecting the proper channels, and they assured us the problem was being worked on. Testing on 17 Mar led us to believe it was fixed, and Microsoft confirmed this later in the day. They told us the problem had been introduced as part of routine web site maintenance earlier in the week. Because it didn't involve customer software, they didn't plan to issue a security bulletin. The risks associated with maintaining systems are well known; I expect an enormous number of people have studied that particular set of transactions since the Passport roll-out. However, any others who looked during the period of vulnerability apparently didn't inform Microsoft. Presumably we won't hear more unless a rash of identity theft generates publicity. Although I've been involved with the Internet for years, I had avoided using my credit card over the net until this month. Given current tools, I'll feel compelled to read the page source before I do so again. ------------------------------ Date: Tue, 11 Mar 2003 10:02:46 +0000 (GMT Standard Time) From: "Ryan O'Connell" Subject: Re: Traffic lights don't work in the snow (RISKS-22.62) This is not a new problem for anyone used to riding a small (125cc - 7.6 cubic inches I believe is the US measurement) motorbike. Many small sports motorbikes are made almost entirely of alloy to reduce their weight. (The Aprillia RS125 is an example) Sometimes, there's not enough metal in the bike to trigger these sensors - leaving you sitting at the lights wondering what to do next. On many roads you can't turn round so you just have to risk running the red light. Fortunately, when this happens it's usually late at night so there's no other traffic about to trigger the lights and therefor no other traffic that can hit you. On a busy road, the risks are obvious. You have no choice but to attempt to join a potentially busy road by going through a red light or ride on the pavement to a safe spot to rejoin traffic. (I usually chose the latter option.) ------------------------------ Date: Tue, 18 Mar 2003 17:05:51 -0800 From: Crispin Cowan Subject: Re: Beware the spelling checker (NewsScan, RISKS-22.64) > ... However, using the software, the two groups made about the same number > of errors -- 16 vs 17. What this experiment does not account for is to compare the 16 or 17 errors in a document assisted by the spelling checker vs. the error rate in documents that are never proof read at all because the author could not be bothered. Crispin Cowan, Chief Scientist, WireX http://wirex.com/~crispin/ HP/Trend Immunix http://h18000.www1.hp.com/products/servers/solutions/iis/ ------------------------------ Date: 29 Mar 2002 (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. Alternatively, via majordomo, send e-mail requests to with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@CSL.sri.com . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address " ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, 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 21" for volume 21] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.65 ************************