RISKS-LIST: Risks-Forum Digest Monday 5 April 2004 Volume 23 : Issue 30 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://www.risks.org> as <http://catless.ncl.ac.uk/Risks/23.30.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: GM recalls Cadillac SRX (Monty Solomon) Firetruck steers itself into tree (Caleb Hess) 800,000 cards overcharged at Wal-Mart stores (Monty Solomon) News24's not-very-restrictive access restrictions (Cody Boisclair) Time records often altered, job experts say (Bob Schuchman) 4.6-million DSL subscribers' data leaked in Japan? (Chiaki Ishikawa) Pilot study of cybercrime against businesses (Michel Kabay) Risks of broadband upgrades (Jeremy Epstein) Too Many Pips! (Andrew Watkins) Fighting back at spam, viruses, etc.? (Neil Youngman) Risks of malicious code in MIDI instruments/robots (Kenji Rikitake) Net hoaxes snare fools all year (Monty Solomon) Re: Bridge construction mismatch (Stephen Poley, Darryl Smith) Re: AT&T Alerts Consumers About the Latest Scams (Pekka Pihlajasaari) Netsky.P and iframe src=??cid variant (Rob Slade) Latest Citibank scam... (Cody Boisclair) Who's in charge of the e-mail virus war, and are we losing? (Steve Summit) Re: Buffer overflows and Burroughs/Unisys (Crispin Cowan) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 2 Apr 2004 17:57:08 -0500 From: Monty Solomon <monty@private> Subject: GM recalls Cadillac SRX General Motors Corp will recall 12,329 Cadillac SRXs equipped with all-wheel drive, following two reports of a software anomaly that causes a one-second delay in the anti-lock brakes activating to stop the vehicle -- reportedly only in the first few seconds of driving when the SUV is moving slowly. One owner crashed his SRX into his garage wall following the brake delay, but was uninjured. (Buick Rendezvous SUVs are also being recalled because of a faulty latch on the liftgate.) [Source: Reuters, 2 Apr 2004; PGN-ed] <http://finance.lycos.com/home/news/story.asp?story=40999216> ------------------------------ Date: Fri, 02 Apr 2004 13:31:39 -0500 From: Caleb Hess <hess@private> Subject: Firetruck steers itself into tree A major US manufacturer of firefighting apparatus has begun offering an electronically controlled all-wheel steering option for its large trucks. The system offers three driver-selected operating modes, in which the rear wheels are either locked in straight-ahead position, or angled with or in opposition to the front wheels. One such truck, owned by the town of Natick, Massachusetts, was recently involved in a collision with a tree. Firefighter union President Danny Hartwell said the truck's rear axles turned on their own as the truck traveled to a call. "The back end wrapped around a tree and there was nothing the guys could do about it," Hartwell said. The truck manufacturer examined an onboard computer and determined the accident was not caused by a mechanical error. However, the analysis also showed human error was not a factor. Quoting from the manufacturer's description, "The entire system is designed for fail-safe operation. System interlocks and a self-diagnostic troubleshooting system are in place to enhance safety and reliability." <http://cms.firehouse.com/content/article/article.jsp?sectionId=46&id=28508> ------------------------------ Date: Sun, 4 Apr 2004 22:30:53 -0400 From: Monty Solomon <monty@private> Subject: 800,000 cards overcharged at Wal-Mart stores [Source: Dan D'Ambrosio, Associated Press, 4 Apr 2004; PGN-ed] A computer hardware problem caused more than 800,000 credit and debit card transactions to be double- or triple-billed last week at Wal-Mart stores nationwide, according to officials at First Data Corp., which handled the electronic payments. The excess Visa and Mastercard charges, which occurred on 31 Mar 2004 and were posted on 1 Apr 2004, have been reversed, First Data spokeswoman Staci Busby said Sunday. [...] <http://finance.lycos.com/qc/news/story.aspx?story=200404050213_APO_V3173> First Data says glitch hit card users at Wal-Mart 4 April 2004, 4:57pm ET, Reuters <http://finance.lycos.com/qc/news/story.aspx?story=200404042057_RTR_N04362746> Wal-Mart Customers Affected by Computer System Disruption at First Data; Toll-Free Number Open for Consumer Inquiries 2 April 2004, 10:31pm ET, PR Newswire <http://finance.lycos.com/qc/news/story.aspx?story=200404030331_PRN__LAF044> ------------------------------ Date: Sun, 04 Apr 2004 19:38:12 -0400 From: "Cody B." <cody@private> Subject: News24's not-very-restrictive access restrictions Oh, my. This one ought to win some sort of award for brazen cluelessness about how the web works... News24.co.za, a popular news site in South Africa, has begun to limit access to articles by international users-- in the same vein as the London Times' Web site, for instance-- allegedly due to "escalating international bandwidth costs". Foreign users of the site must pay a monthly registration fee in order to read the latest news from South Africa. One minor oversight, though: users are forwarded to the registration form in question by means of a Javascript redirect. Thus, foreigners can read all of News24's articles in full, at absolutely no cost, *simply by turning Javascript off*. I don't even think I need to point out the many things that are utterly wrong with this. Cody "codeman38" Boisclair <http://www.zone38.net/> cody@private ------------------------------ Date: Sat, 03 Apr 2004 12:23:07 -0800 From: Bob Schuchman <schuchmanr@private> Subject: Time records often altered, job experts say Here's another data modification risk: a manager altering computerized time-card records to "shave time" -- reducing the hours worked by employees, "secretly deleting hours to cut their paychecks and fatten his store's bottom line." [Source: *The New York Times* 4 Mar 2004; PGN-ed] <http://www.nytimes.com/2004/04/04/national/04WAGE.html?hp> ------------------------------ Date: Sun, 21 Mar 2004 01:54:11 +0900 From: Chiaki <ishikawa@private> Subject: 4.6-million DSL subscribers' data leaked in Japan? By now, the scope of the leak of 4.6 million name has been confirmed. That is basically Yahoo/BB, the ADSL company operated by SoftBank and the police sources admitted that the list is part of the genuine current active users save for the subscribers who have stopped the subscription. SoftBank kept these names in case some inquiries were made from former subscribers. Now, regarding the problematic data handling policy, the following is widely reported in the Japanese press. Access logs to the data server which held the name of the subscribers were removed after one week : this makes the tracing of the route via which the leak was made almost impossible, it seems. SoftBank claims that it has lengthened the life of log files now. There were too many people with authorized access : one account I read in a magazine stated 135 people could access it inside the company. Adding insult to the injury, the password and ID pairs for these authorized personals seemed routinely be handed out whoever "needed" to access the list at the whim of the moment. That is, only about 40 pairs of account and password pairs were issued among 135 people. Now how can anyone reasonably figure out where the leak was? Really a good example of what one should NOT do in handling sensitive information and seeing it at an large ISP is rather disappointing and disgusting. Yahoo BB, the ADSL service company decided to send coupon worth 500 YEN (slight less than 5 dollars) to people whose name was leaked as a gesture of apology. I have no idea where this 500 YEN figure came from. It seems to too cheap to me. One irate customer of Yahoo/BB did quite a striking opinion piece by selling his "personal information", exactly the info which was believed to be in the mentioned DVD, on non other than Yahoo auction site. He started the bid at the same 500 YEN which Yahoo/BB seems to regard it to be worth, but then after 150 bids, the price went up to more than 1.5 million YEN. I have not followed it and so I don't know if the auction item was removed from the site since it is "anti-social", etc.. This incidence is a really good example of what we should not do and many organizations seem to take this example seriously. In that sense, it is a good thing, but I have no idea what bad things may happen due to the leaked list. ------------------------------ Date: Thu, 1 Apr 2004 21:40:54 -0500 From: "Michel Kabay" <mkabay@private> Subject: Pilot study of cybercrime against businesses "Cybercrime against Businesses: Pilot Test Results, 2001 Computer Security Survey" (12 pp.) (NCJ 200639) describes the history, development, and implementation of the pilot Computer Security Survey conducted during the last half of 2002. It provides recommended improvements to be incorporated in the final questionnaire, which BJS anticipates fielding in FY 2004. (BJS) [National Criminal Justice Reference Service <http://www.ncjrs.org>, 1 Apr 2004, Vol 10, No 7] <http://www.ojp.usdoj.gov/bjs/abstract/cb.htm> ------------------------------ Date: Fri, 2 Apr 2004 12:40:50 -0500 From: Jeremy Epstein <jeremy.epstein@private> Subject: Risks of broadband upgrades Cox Communications is currently (8:45am EST 2 Apr 2004) suffering from a widespread outage among Virginia customers who have Toshiba 1100 series cable modems. As best as I've been able to find out from their "support" people and web page, it was an upgrade gone bad. The outage at this point has been 22 hours, and there's no estimate for when it will be fixed. At this point there are more questions than answers, including: * Why is this only impacting customers with Toshiba cable modems (which, incidentally, is the brand Cox recommends!) * What specifically did they change that's causing the problem? * Why is it only impacting Virginia Cox customers? * Why wasn't there a recovery plan in place before pushing out a change like this? On the positive side, this is an example of where diversity really *does* make the system more resilient: customers with other brands of cable modems are (for whatever reason) apparently immune to whatever went wrong. [For anyone tempted to get useful information from the Cox web page, it incorrectly claims that the outage started at 7:45pm, when in fact it started no later than 2pm, and probably earlier than that.] Update at 12:45amEST: A (purported) Cox representative reported <http://www.dslreports.com> that "we have an outage on a subset of our Toshiba cable modems in Northern Virginia. While performing software upgrades (DOCSIS 1.1) some of our Toshiba PCX1100 modems went off-line and are not able to come back up. [...] [we have performed this identical upgrade to many other Toshiba modems in other cities, so we're trying to determine what was unique in the NOVA case.]" I haven't gone back and read the terms of service to see if they have the right to update the software in a modem that I own.... ------------------------------ Date: Thu, 1 Apr 2004 09:51:13 +0100 From: "Andrew Watkins" <andrew@private> Subject: Too Many Pips! BBC Radio 4 is the primary news and current-affairs Radio service in the UK. The Greenwich Time Signal (The Pips) is a sequence of 5 short pips spaced 1 second apart followed by a longer pip, marking the turn of the hour. This 'official' time check allows people to set their watches accurately. On 23rd Mar 2004 the pips were heard on air at 12:14:55 and 17:14:55. According to a source at the BBC, "We generate pips every 15 minutes, and the Studio Manager has to press a button to select the pips in the 14 minutes before the pips are needed. In the old Radio 4 studio, once a set of pips went through, they self-cancelled (unless the SM had put them on a channel of the desk and faded them up, which they might do for operational reasons) ... but they don't self-cancel in the new studio. We seem to have had two Studio Managers that day who had completely forgotten that they don't self-cancel. Sadly, as more and more new systems come on line over the next year or so, the inability of those designing the systems to properly evaluate and mitigate the risks and the lack of experience of those using the systems will inevitably lead to an increase in such errors." Andrew Watkins, Newland Software ltd. tel: +44 1926 640073 (01926 640073) <http://www.newlandsoftware.ltd.uk> ------------------------------ Date: Tue, 30 Mar 2004 17:43:43 +0100 From: Neil <no.spam.for.n.youngman@private> Subject: Fighting back at spam, viruses, etc.? According to esecurityplanet.com, a company called Symbiot is planning to launch a network security tool offering countermeasures "graduated from blocking and quarantining to more invasive techniques" <http://www.esecurityplanet.com/prodser/article.php/11166_3327391_2> The article points out may of the risks associated with aggressive counterattacks. Also *The Register* claims that a Trojan is being distributed on file sharing networks, masquerading as pirate software. "The programs have circulated disguised as activation key generators and cracks for Unreal Tournament 2004, Pinnacle Studio 9, Norton Antivirus, TurboTax" <http://www.theregister.co.uk/content/55/36391.html> While this Trojan appears not to carry a dangerous payload, there's no doubt that something like this could be used to carry out some seriously malicious actions. ------------------------------ Date: Thu, 1 Apr 2004 20:03:15 +0900 From: Kenji Rikitake <kenji.rikitake@private> Subject: Risks of malicious code in MIDI instruments/robots (Re: PGN, R 23 29) On music-playing robots: the MIDI protocol specification defines System Exclusives, which allows sending almost any kind of data without any authentication, directly to the instrument's memory. Without performing proper sanitization, any sort of System-Exclusives data can cause unexpected problems, rhythms, notes, and tunes. I hope the music-playing robots were well-protected from such attacks. [Seems unlikely. PGN] ------------------------------ Date: Wed, 31 Mar 2004 23:14:36 -0500 From: Monty Solomon <monty@private> Subject: Net hoaxes snare fools all year <http://wired.com/news/culture/0,1284,62794,00.html> ------------------------------ Date: Thu, 01 Apr 2004 15:22:41 +0200 From: Stephen Poley <sbpoley@private> Subject: Re: Bridge construction mismatch (Knowlton, RISKS-23.29) > one half [of the bridge] had been built 54 cm lower than the other My off-the-cuff reaction to this was to wonder if the problem was caused by a difference in datum sea-level height between Germany and Switzerland [calculated at the North Sea and the Mediterranean, respectively] -- and to wonder how civil engineers would fail to think of that. [See PGN note.] Well, according to <http://www.kopa.ch/img_upload/az_bruecke.htm>, that was indeed the cause. But the difference between Germany and Switzerland is not 54cm, but 27cm! I don't think I need to spell out the rest to RISKS readers. Incidentally the discrepancy is not between the two halves of the bridge, but between the bridge and the roadway on the German side, so it appears the bridge itself was (sensibly) all surveyed from the same baseline. [Indeed, the engineers had thought of the difference, as it is widely known in their community, but unfortunately they corrected it in the *wrong* direction, as also noted by Pete Kaiser and Markus Fleck-Graffe. PGN] ------------------------------ Date: Thu, 1 Apr 2004 16:33:31 +1000 From: "Darryl Smith" <Darryl@radio-active.net.au> Subject: Re: Bridge construction mismatch (Re: Knowlton, RISKS-23.29) Unfortunately, this is not as uncommon as it would appear. Here in Australia, Wallerawang Power Station was built over a period of about 40 years or so using two or three height datums. They started with the 'A' station, followed by the 'B' and 'C' stations. Then removed most of the 'A' and 'B' stations. The problem was that the original site works were done on the 'A' datum which was about a meter different from the 'C' datum. This did not matter until they wanted to build a non-local coal conveyor system to replace bringing coal in by truck. Some of the design was done for the 'C' datum and some at the 'A' datum - without the knowledge of the designers. This was only discovered once construction started, and the resulting dispute ended up in court. Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia Mobile Number 0412 929 634 [+61 4 12 929 634 International] www.radio-active.net.au - www.radio-active.net.au\web\tracking ------------------------------ Date: Fri, 2 Apr 2004 22:03:14 +0200 From: "Pekka Pihlajasaari" <pekka@private> Subject: Re: AT&T Alerts Consumers About the Latest Scams (RISKS-23.29) This RISK was not at all clear until I recalled that in the United States many cellular calls are mostly charged to the recipient. In many networks, GSM included, the caller is charged for the full cost of the call and the recipients only pay for routing calls while the subscriber is roaming across networks. The RISK is assuming that business models and technical constraints are globally applicable. Pekka Pihlajasaari, Data Abstraction (Pty) Ltd pekka@private ------------------------------ Date: Thu, 25 Mar 2004 12:31:27 -0800 From: Rob Slade <rslade@private> Subject: Netsky.P and iframe src=??cid variant I assume that everyone is, by now, well aware of the Bagle.Q virus that used an interesting trick to spread a virus via e-mail without an attachment. Netsky, in its latest incarnation, appears to reverse that in an intriguing twist. I have noted, in the past few days, the sudden spurt of Netsky.P messages, and, simultaneously, queries about messages containing the string "iframe src=??cid:" in the body. (In the samples I've got the ?? has been 3D, but I don't know if this is the same in all cases.) In the Netsky.P infected messages as they are described in the virus encyclopedias (I have checked F-Secure and Sophos in detail), the message carries a standard attachment, in the normal MIME format as: Content-Type: application/octet-stream; name="photo.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="photo.zip" There are a few twists on this: occasionally the filename has the username in it, such as document_rslade.zip. In some cases the filename a multiple extensions and a large number of spaces, such as: document.txt .exe which is a fairly obvious attempt to convince people that the attachment is a harmless text file. (Netsky, like most other recent e-mail viruses, uses a wide variety of subject lines and message bodies, and spoofs the "from" line using addresses harvested from the infected machine.) From samples I have extracted of the "cid" postings, these messages are a version of Netsky.P: the executable file is the same size (29,568 bytes) and a quick look at the internal contents seems to be the same. F-Prot DOS with signatures as of 20040321 identifies it as Netsky.P. The important part of the internal structure of the message follows the general form: <BODY bgColor=3D#ffffff>If the message will not displayed automatically,<br> follow the link to read the delivered message.<br><br> Received message is available at:<br> <a href=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0>www.sprint.ca/inbox/rslade/read.php?sessionid-1165</a> <iframe src=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0></iframe> <DIV> </DIV></BODY></HTML> ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: audio/x-wav; name="message.scr" Content-Transfer-Encoding: base64 Content-ID:<031401Mfdab4$3f3dL780$73387018@57W81fa70Re> Note that, in a reverse of the Bagle.Q trick, the URL does not actually point to an external Web site, but to a subsequent part of the same message. (In all the samples I have received the filename used is message.scr.) The structure of the message appears to use two different known vulnerabilities in Outlook. (Given the numbers of Netsky.P that I am receiving, it is rather depressing to note that vulnerabilities that were known, in general terms, as far back as 1997, and specifically patched as early as 2001, are still effective. People, if you must use MS products, please keep them patched!) Because of the use of the iframe vulnerability, users of mailers other than Outlook may see the message appear in various ways. In Pegasus (which I use) the message has no body, but does have a normal attachment. (In most viruses that use iframe to directly invoke the attachment, Pegasus doesn't show any attachment.) I note that neither the Sophos nor the F-Secure encyclopedias mention this version of the message. The Trend advisory does mention the iframe vulnerability (without giving details) but not the second, and also does not mention the non-iframe version of the messages. (Having two radically different forms of messages appears to be similar to Swen.A and Swen.B, both of which produce two different types of messages, each of which is somewhat polymorphic within the version.) rslade@private slade@private rslade@private <http://victoria.tc.ca/techrev> or <http://sun.soci.niu.edu/~rslade> ------------------------------ Date: Sat, 27 Mar 2004 13:05:43 -0500 From: "Cody B." <cody@private> Subject: Latest Citibank scam... I just received yet another one of those Citibank scams. Normally my attitude toward these things is simply one of annoyance, because they use old tricks that *should* be well-known by now, such as the fact that anything before an @ sign in the first part of a URL is interpreted as a username-- but this one was a bit more devious than most of the scams I've seen so far. Reminiscent of the PayPal scam reported by Jacob Palme in RISKS 23.13, this particular scammer eschewed using the username-in-URL trick, and instead registered a vanity domain name with 'citibank' in it! Specifically, the domain was securecitibank.us, which is registered to one Wayne Stanford in Marina, CA according to a whois lookup. <http://www.whois.us/whois.cgi?TLD=us&WHOIS_QUERY=securecitibank.us> Just as in the scam Palme reported, the actual URL used http rather than https, but gave the appearance of 'security' to the untrained eye because of the rather deceptive domain name used. I wasn't fooled, of course, for a number of reasons-- most significant probably being the fact that I have no Citibank account because they have no branches in my state-- but I can see how someone who knew a bit less about the workings of the Internet and who actually had an account with the bank in question could easily be fooled by such trickery... Cody "codeman38" Boisclair cody@private <http://www.zone38.net/> ------------------------------ Date: Thu, 25 Mar 2004 10:54:02 -0500 From: Steve Summit <scs@private> Subject: Who's in charge of the e-mail virus war, and are we losing? Three or four big virus outbreaks ago, there was a disturbing sentence in a Boston Globe article by Hiawatha Bray, along the lines of, "Clearly, computer experts still don't know how to stop these outbreaks." My immediate thought was, "Of course we do! Don't write e-mail clients that make it easy to execute untrustworthy, received, executable content!" But then I imagined a likely riposte to my assertion: "Sure, lots of problems can be solved if you're allowed to go back and rewrite and replace everything, but how can we solve the problem given the e-mail programs that are out there?" This imaginary conversation got me to thinking: what is the general consensus, not just among RISKS readers, but across the computing industry as a whole, as to the appropriate strategy for dealing with e-mail viruses? I'm certainly not alone here in assuming that the best way, and in fact the only way, of truly eliminating the problem is to eliminate the e-mail clients -- all of them, even if it takes a while -- which do make it easy to execute untrustworthy, received, executable content. But lately I'm not so sure that this solution is so self-evident to the industry at large. Whenever a new one of these viruses hits, the visible reactions are always the same: hasty updates to "antivirus" software, new exhortations to end users not to open suspicious attachments, new ad-hoc rules implemented in corporate e-mail gateways which block certain potentially- dangerous filename patterns (also known as "file types") in attachments. Notice how these responses are all reactive, and dance around the real problem. My fear, then, is that the fundamental enabling mechanism for most of these e-mail viruses -- namely, the fact that a user of a popular graphical e-mail client need only click on an executable attachment to run it -- is being or has already been tacitly reclassified. I would have blandly asserted that this aspect of those e-mail clients is and has always been a bug, but: what if it's now, so help us, an *axiom*? If the world at large, and those portions of the computer industry that cater to the world at large, believe that any solution to the virus problem must be designed around the "fact" that users must be able to click on executable attachments and have them run, then I'm afraid the battle is lost. That assumption concedes a huge and tragically unnecessary upper hand to the virus writers, an upper hand which is basically unbeatable. If this assumption is, in fact, in the process of being ordained, what can we (who assume otherwise) do about it? [If you wish to take Steve's bait and respond, PLEASE send your comments directly to him. He will summarize the responses for RISKS. TNX. PGN] ------------------------------ Date: Thu, 04 Mar 2004 17:07:51 -0800 From: Crispin Cowan <crispin@private> Subject: Re: Buffer overflows and Burroughs/Unisys (Hopkins, RISKS-23.24) > Heck, software can always make up for hardware deficiencies, right? That's a perspective, but I disagree. Burroughs was not the only lab to experiment with language support on chip. Intel also tried this, with the i432. The result was that the RISC processors produced *crushing* performance wins over chips with complex semantics, due to the ability to heavily pipeline and thus ramp up the clock on simple instruction sets. Thus hardware semantics enforcement ended because the hardware people discovered that it was easier to do in software. Continuing this tradition, software semantics enforcement more or less ended when software people discovered that it was easier to do in marketing :) [Crispin, in the business of software semantics enforcement] [To which Bill Hopkins retorted:] > Hardware semantics enforcement is impossible unless programs have > enforceable semantics. C doesn't provide them, so Crispin has a business. Hey! C provides the semantics of a PDP11 quite well :) C is not a programming language. C is God's Own Portable Macro Assembler. Never forget that, and you'll know when it is appropriate to write code in C. CTO, Immunix <http://immunix.com> <http://immunix.com/~crispin/> ------------------------------ Date: 5 Apr 2004 (LAST-MODIFIED) From: RISKS-request@private 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 <risks-request@private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; 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 <Lindsay.Marshall@private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@private with meaningful SUBJECT: line. *** NEW: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i] <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay 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/> . ==> 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 23.30 ************************
This archive was generated by hypermail 2b30 : Mon Apr 05 2004 - 16:44:50 PDT