RISKS-LIST: Risks-Forum Digest Tuesday 27 August 2002 Volume 22 : Issue 21 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 <URL:http://catless.ncl.ac.uk/Risks/22.21.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: VeriSign error teaches lawyer a lesson (Max) Automation increases anxiety -- with cause (Fuzzy Gorilla) Big Brother hiding inside cars' airbags (Monty Solomon) Keystone SpamCop summary and response (Edward W. Felten) SpamAssassin killed off RISKS-22.20 (Danny Burstein) Re: "Homeland Insecurity" (Stephen Fairfax) Re: Your packets know the way to San Jose (Barry Margolin, Steve Wildstrom, Gene Wirchenko, R.G. Newbury) Re: YASST: Yet Another Silly Spam Trick (Tai) Re: Klez: The Virus That Won't Die (Excimer, Scott Peterson) REVIEW: "Access Denied", Cathy Cronkhite/Jack McCullough (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 25 Aug 2002 08:16:20 -0700 From: Max <max7531at_private> Subject: VeriSign error teaches lawyer a lesson Fremont, California, attorney Anu Gupta's Web site www.immigrationdesk.com was mistakenly transferred to a company in India, as the result of an error by VeriSign. (She helps people get visas, green cards and other documents.) After five days of haggling with VeriSign, Gupta eventually regained control of the site, but only after she threatened to sue. E-mail sent during that time disappeared, and could have included credit card and tax information. [Source: Lawyer learns hard lesson on wild, wild Web, Peter Delevett, *San Jose Mercury News*, 25 Aug 2002; PGN-ed] http://www.bayarea.com/mld/mercurynews/news/local/3935313.htm From the article: VeriSign has garnered a reputation for shoddy customer service and questionable marketing. A federal court ruled in June [2002] that the company had poached competitors' customers by sending them bogus renewal letters, and several related lawsuits are pending. The Federal Trade Commission is also investigating VeriSign's marketing. ... The real pity for Gupta and other disgruntled Internet users is that there's no enforcement body standing up for them. ------------------------------ Date: Sat, 24 Aug 2002 12:19:00 -0400 From: "Fuzzy Gorilla" <fuzzygorillaat_private> Subject: Automation increases anxiety -- with cause People are often worried about computerization for a good reason. Even though it is the same information, the potential risks from abuse are increased. Black lists, blackmail, and sending private information to the wrong parties were all reported. [FG] There is considerable controversy in Japan at the moment over an attempt to put personal information on-line in a family-registry database, along with an 11-digit identifying number for everyone. In addition to fears relating to hackers and criminals, "one of their chief concerns is misuse of the data by their own government." Polls show huge majorities are against the system. [Source: Plans to Computerize Personal Data Ignite Firestorm in Japan; Citing Privacy, Municipalities Defy Effort By Doug Struck, *The Washington Post*, 23 Aug 2002, A18; PGN-ed] http://www.washingtonpost.com/wp-dyn/articles/A51216-2002Aug22.html From the article: There is plenty of grist for public suspicion of bureaucrats. In May, the Defense Agency admitted it had drawn up a list with names, backgrounds and political views of citizens who had asked for public information from the agency. Twenty-nine agency officials were punished. Last month, defense contractor Fujitsu said it had gotten a blackmail demand from men who had obtained personal information on military officers leaked from the company's computers. And just as Juki Net started up, embarrassed officials in the city of Moriguchi in Osaka acknowledged they had sent personal information about 2,584 individuals to the wrong people. ------------------------------ Date: Thu, 22 Aug 2002 19:09:12 -0400 From: Monty Solomon <montyat_private> Subject: Big Brother hiding inside cars' airbags On 11 Feb 2002 on Union Road in Trotwood, Ohio, a 1999 Pontiac Trans Am skidded sideways off the road, went airborne for 110 feet, and eventually hit a utility pole. An estimate of the car's speed was upgraded after examining an onboard electronic monitoring device in the airbag control mechanism, which pegged the speed at 124 mph (in a 40-mph zone). [Source: *Dayton Daily News*, By Cathy Mong, cathy_mongat_private; PGN-ed] http://www.activedayton.com/ddn/local/0822car.html ------------------------------ Date: Mon, 26 Aug 2002 11:45:27 -0400 From: "Edward W. Felten" <feltenat_private> Subject: Keystone SpamCop summary and response (Re: RISKS-22.19) [HTML version (same text, but somewhat easier to read) available at http://www.freedom-to-tinker.com/archives/000023.html] I received 59 responses to my SpamCop narrative. Because there are so many, I cannot respond individually to each one. Instead, I summarize below the major arguments raised by the messages. I give sample text from messages that asserted each argument, and I respond. This posting is rather long, and some readers may not be interested in the whole thing, but I think the people who sent me constructive messages about the SpamCop incident deserved a response. Argument 1: Blame the ISP, not SpamCop. Sample: "The problem is not with Spamcop, but rather with your ISP. The ISP is required to assert that they have dealt with the issue, not that they have shut the website down. They can mark the issue 'resolved' with spamcop and then work with you to discover the true nature of the problem. The choice to shut the web site down now, and investigate later, was your ISP's, not Spamcop's. " Another sample: "However, in this case, your ISP is responsible for bouncing your domain, not SpamCop. All SpamCop e-mails come with a link to the original report, so it was _your_ ISP who failed to research this and _your_ ISP who is to blame for suspending your site." My response: Certainly my ISP is the party who actually pulled the plug on my site. The ISP was intimidated by SpamCop and seemed to be trying to show that it was responsive to SpamCop complaints. Hence the quick shutoff of my account. Yet even after I convinced my ISP that I was not a spammer, they still refused to reinstate my site, saying that to do so before SpamCop removed the complaint against me from its site would put the ISP's other customers at risk. This refusal to reinstate my account is what convinced me that the ISP was afraid of SpamCop. Whether the ISP was right to fear SpamCop, I cannot say. What I know is that the ISP chose to anger a paying customer, rather than risking what they perceived as the wrath of SpamCop. The fact that SpamCop engenders such fear is a big part of the problem. For me, the bottom line is this: if SpamCop didn't exist, my site would not have been shut off. Argument 2: SpamCop doesn't block sites, ISPs block sites. Sample: "SpamCop (http://www.spamcop.net) blocks nothing. SpamCop does have a DNS-based blackhole list that ISPs have the option of using---for example, I use it for all my domains as a backup to my own block list." Another sample: "The spamcop blocklist is supposed to be used in order to tag certain email as possible spam. It is not to be used to block email (although some ISP's do use it that way)." Another sample: "ISPs also use Spamcop, but it is the ISP, not Spamcop, that makes the determination whether something listed by Spamcop is deleted, flagged, or passed through. I happen to delete." My response: Nearly everybody who made this argument followed it by saying that they themselves do automatically block sites on the block list, or that many others do. This is hardly surprising. Even a perfect block list would do little good unless people used it to block. The alternative use of shunting aside email from sites on the list, and reading it later, doesn't do much to address the spam problem. As far as I can see, there are only two sensible things to do with a block list: you can ignore the list, or you can use it to block sites. That's why they call it a "block list." That's why SpamCop's site gives instructions for configuring common mail servers to block addresses on the list. SpamCop can hardly be surprised to see ISPs following these instructions and blocking the addresses on what SpamCop itself calls a "block list." Argument 3: SpamCop is just a clearinghouse for spam complaints and simply routes complaints that could have been sent even in the absence of SpamCop. Sample: "SpamCop is a machine. It summarizes and reports what human individuals feed it. Another sample: "SpamCop is primarily a _reporting_ service which allows a user to easily report email abuse to the appropriate authorities. It has a parser which cracks email header information and figures out the true source of the email (as much as possible) despite forged header information. This is just the same as manually email[ing] a complaint, but automates the header analysis (which can save a lot of time when the headers are intentionally obfuscated). A user does not 'send an accusation to SpamCop' but uses SpamCop to email a complaint to abuse or postmaster addresses." My response: SpamCop does more than just forward complaints. It anonymizes the complainant's address, thereby making it harder for the ISP receiving the complaint to judge the complaint's credibility. SpamCop puts the complaint on the Web for others to see. And SpamCop tries to find patterns among its complaints, and adds addresses to its block list based on these patterns. All of these factors contributed to my dilemma. If SpamCop were merely a complaint router, then SpamCop would be ineffectual. It is SpamCop's "value added" that caused me trouble. Argument 4: Blame the person who erroneously reported the "spam," don't blame SpamCop. Sample: "The SpamCop user, not SpamCop itself, is ultimately responsible for what is sent. Each report has been individually submitted by a user, then individually selected by the user before sending." Another sample: "The 'mistaken' reporter of spam violated SpamCop's terms of service, period. It doesn't matter if you call 911 to report a fire or a burglary: at the end of the day, individuals are responsible for their reporting, the telephone company is not to be blamed for prank calls to 911." My response: This is really just a variant of Argument 3, and fails for the same reasons. SpamCop is ultimately responsible for its reporting, too. The 911 analogy doesn't apply, since the phone company merely receives the report but SpamCop repeats reports and amplifies them. SpamCop took what would otherwise have been a private report, to be dealt with between the reporter and my ISP, and posted it for the whole world to see. And it gave the report increased credibility and force. Argument 5: The attributes of SpamCop that Felten complained about are necessary to prevent spam, or to prevent retaliation by spammers. Sample: "In the absence of anti-spam laws with teeth, technical[ly] shunning ISPs who deliberately harbor spammers is the only alternative to control spam." Another sample: "[SpamCop anonymizes the complainant's address because] real spammers might take action against a spam reporter, such as using their address as the 'From' on a spam run." My response: Yes, SpamCop's designers had good intentions. Yes, effective spam-fighting was their goal. My point is that in their zeal to fight spam, they built a system that overreacts to erroneous or malicious spam reports. I for one would not be willing to accept that kind of collateral damage, even if doing so would completely prevent spam (which it cannot). Several people said that SpamCop is slower to act against accused parties than some other anti-spam services are. That may well be true. If it is, then the other services are presumably causing even more collateral damage. Argument 6: Felten really is a spammer. "[Quoting Felten: ]'Never mind that I had never sent a single e-mail message from the site.' Reply: Someone did: Mail for freedom-to-tinker.com is handled by freedom-to-tinker.com (0) 209.51.158.242 http://www.samspade.org/t/dns?a=freedom-to-tinker.com If you look here, you will see two different headers that came from this IP address, both of which are dated July, 31: http://spamcop.net/w3m?action=checkblock&ip=209.51.158.242 Those are only examples; there could have been many more spams reported through that address." My response: I did not send those messages. The writer apparently believes that if the messages came from "my" IP address, then I must be responsible for them. But it's not my IP address -- it's shared by many of my ISP's customers. Perhaps the cited messages came from one of them. This argument nicely illustrates the problem with SpamCop. By collecting complaints in one place and indexing them, SpamCop facilitates the making of this kind of accusation. And by repeating allegations made by others, SpamCop gives them more credibility than they deserve. ------------------------------ Date: Thu, 22 Aug 2002 21:44:29 -0400 (EDT) From: danny burstein <dannybat_private> Subject: SpamAssassin killed off Risks Digest 22.20 I run SpamAssassin (RISKS-22.08-10) using the default settings. (I push tagged mail aside into a spam box for leisurely review so I'm not too worried about false positives.) It didn't like the latest issue of RISKS. Meaning, alas, that if people are using SpamAssassin to reroute (suspected) spam to the trash pile, or worse, if the ISP is using it ahead of the subscribers, many copies never got to the intended recipient. ------------------------------ Date: Thu, 22 Aug 2002 20:05:10 -0400 From: Stephen Fairfax <fairfaxat_private> Subject: Re: "Homeland Insecurity" (RISKS-22.20) Mann's article (RISKS-22.20) is indeed timely and well-written, but with all due respect to both Mann and Bruce Schneier, I believe they miss some important points. It's fine to suggest that systems fail smartly, or well, or not be brittle, but often designers are limited in choosing how systems fail. Complex systems have an annoying habit of exhibiting new and unforeseen failure mechanisms. Ultimately the failure mode is determined by laws of physics (for machines) or human behavior and are not easily controlled. That isn't to say that one can't select the most robust method of mitigating the consequences of failure, but practically speaking, the options are often quite limited. What is not so severely limited, and what I feel is largely absent from the present approaches to security, is formal, quantitative analysis of what happens AFTER the first failure. My company applies the techniques of Probabilistic Risk Assessment (PRA) to high-reliability power systems for data centers, banks, hospitals, etc. There are many lessons to be learned, but one of the most important is that of layers. Once you understand that a particular failure can occur, you examine its consequences and make an informed choice about whether the system should be designed to continue functioning after that failure. If so, you generally need to add either redundant components, or some new system to handle the failure. In both cases, you need to take care that the cause of the initial failure is unlikely to compromise the response. One can take advantage of knowledge of the system state after the failure in designing the next layer of protection. For example, if utility power fails, you can use the fact that most outages are brief, less than a few minutes, to rely on battery back-up rather than immediately starting standby engine-generators. This saves wear and tear on the engines, and helps one to select the appropriate discharge time rating for the batteries. If the outage lasts more than 2 minutes, the engines are started, and now the operators know that the outage is likely to last at least 30 minutes or longer, and can plan their actions accordingly. PRA formalizes and quantifies this kind of thinking. Applied to the problem of airport security, it offers a way to evaluate the effectiveness of various proposals. It doesn't take much analysis to show that successive "random" screenings, using the same tools, techniques, and personnel as the original, 100% screening of passengers, adds essentially zero value. (Aside: I always ask to see the dice, and never have. RISKS readers know full well the process is not random, but merely a concealed method of selection.) On the other hand, a targeted screen, applied after the 100% initial screen, by specially trained individuals, and using different methods (such as pointed, face-to-face questioning, as practiced by some non-US airlines) can yield large improvements. You can trade off the training and tools applied to the initial screen and the secondary screen to get the best result for a given level of investment. Nearly all security analysis seems to ignore or completely discount the actions of lawful passengers after security failures, but the examples of Flight 93 and the apprehension of the would-be shoe-bomber suggests that this layer of defense is very robust and surprisingly capable. The "good guys" vastly outnumber the "bad guys," our thinking should take advantage of that fact! Guns in the cockpit represent an independent layer that does not automatically fail when screens fail. While there is heated debate about the possibilities of negative consequences, a dispassionate analysis of the probabilities of both success and failure offers rather overwhelming evidence that on balance, armed pilots will reduce both the likelihood and consequences of hijacking attempts. In summary, while it is certainly important to have systems fail gracefully when possible, it is not always possible. That does not excuse the architects of security systems from performing careful, quantitative, reviewable analysis of their designs. Like cryptography, public review and discussion of the algorithms used in truly well-designed security systems will not compromise their integrity. Stephen Fairfax, President, MTechnology, Inc., 2 Central Street Saxonville, MA 01701 1-508.788.6260 fairfaxat_private www.mtechnology.net ------------------------------ Date: Thu, 22 Aug 2002 23:08:41 GMT From: Barry Margolin <barmarat_private> Subject: Re: Your packets know the way to San Jose (Purvis, RISKS-22.20) I think they may be overestimating how much traffic goes through MAE-West. All Tier-1 ISPs have private peering interconnects, we don't use any of the public peering points to exchange data with each other. I don't have any statistics to back me up, but I expect that most Internet traffic goes through these private interconnects, not the public ones, which are used for connections to and between smaller ISPs. Also, MAE-West is just one of several public peering points in the continental US, and nationwide backbones usually connect to each other using at least two (we make that a requirement of all our peering partners -- an ISP that can't meet our criteria has to purchase normal ISP service from us, rather than being a peer). Destroying that building would certainly have an impact on the Internet, as all its traffic would have to be rerouted, and would cause congestion at the other interconnects. For the most part, this would happen automatically (I qualified this, because some ISPs have misconfigured routers, so they don't advertise all their routes at all the exchange points), although it would probably take several minutes to stabilize. To deal with the congestion at the other exchanges, I expect that most of the Tier-1's would relax their transit rules, so that some of it would be shunted to those private interconnects I mentioned earlier. We did similar things last year in the wake of 9/11. Barry Margolin, barmarat_private, Genuity, Woburn, MA ------------------------------ Date: Thu, 22 Aug 2002 20:44:11 -0400 From: Steve Wildstrom <steve_wildstromat_private> Subject: Re: Your packets know the way to San Jose (Purvis, RISKS-22.20) MAE West is only the beginning. There are also MAE East, MAE Central, MAE Chicago, MAE Los Angeles, MAE Paris [MAE OUI?], and MAE Frankfurt -- all owned and operated by WorldCom. I've been surprised by how little public discussion there has been about the amount of critical infrastructure controlled by WorldCom. Should we be very afraid? I know that WorldCom is operating more or less normally under bankruptcy protection and it is in the interest of the creditors that the Internet business remain alive as a going concern, but still, it is a dangerous and potentially very unstable situation. At a minimum, there isn't going to be any investment in these facilities at least until the future of WorldCom is decided.Given the fact that potential buyers can't perform due diligence until the auditors get to the bottom of the accounting mess, the uncertainty could last a long time. Steve Wildstrom Technology & You Editor Business Week 1200 G St. NW Suite 1100 Washington DC 20005 1-202-383-2203 ------------------------------ Date: Fri, 23 Aug 2002 03:31:33 GMT From: genewat_private (Gene Wirchenko) Subject: Re: Your packets know the way to San Jose (Purvis, RISKS-22.20) > also see that MAE West is owned by WorldCom. ^ I think you left out "partly", Mr. Purvis. At the bottom of it is "Southern Cross is owned by Telecom New Zealand (50%), Optus (40%) and Worldcom (10%).". ^^^ That is just a bit different, no? ------------------------------ Date: Thu, 22 Aug 02 21:26:04 -0500 From: "R.G. Newbury" <newburyat_private> Subject: Re: Your packets know the way to San Jose (Purvis, RISKS-22.20) IIRC, MAE East is part of a parking structure.... You can drive up and park next to it.. I suspect it would not take more than a Volkswagen Beetle sized car b*mb to inflict major disruption. Do you think that *anyone* in the "intelligence business" (yes, I *know* that that is an oxymoron) is worrying about the security of this portion of the Internet??? ------------------------------ Date: Fri, 23 Aug 2002 09:26:25 +0000 From: Tai <taiat_private> Subject: Re: YASST: Yet Another Silly Spam Trick (Slade, RISKS-22.20) My wife is convinced that hotmail is a spammer. She created an account that was never given out, and received spam all the time. 6 months later, so forgot the password, and created another account. This account does not receive spam at all. The difference? The first acct belonged to a .usian with .us zip codes, etc. The second acct had an address in some third world country, ie, not .us based. ------------------------------ Date: Fri, 23 Aug 2002 13:15:30 -0400 From: Excimer3at_private Subject: Re: Klez: The Virus That Won't Die (RISKS-22.20) Viruses are becoming more sophisticated, we know that. We also know that they will get worse as they become more and more advanced. Here's a thought: Imagine a Klez descendant with a small distributed-computing payload. Each infected system becomes a node in a neural net. This net would be slow, and the nodes would come and go, but it would be immense and uncontrollable. The possible implications are scary. Science fiction becomes science fact. ------------------------------ Date: Thu, 22 Aug 2002 22:00:12 -0700 From: Scott Peterson <scottp4at_private> Subject: Re: Klez: The Virus That Won't Die (RISKS-22.20) Maybe the even bigger irony is that Microsoft released a patch for Internet Explorer that stops KLEZ dead in its tracks in March, 2001. It's also included in current service packs for it. http://www.microsoft.com/technet/security/bulletin/MS01-020.asp ------------------------------ Date: Thu, 22 Aug 2002 10:06:22 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Access Denied", Cathy Cronkhite/Jack McCullough BKACCDEN.RVW 20020604 "Access Denied", Cathy Cronkhite/Jack McCullough, 2002, 0-07-213368-6, U$24.99 %A Cathy Cronkhite %A Jack McCullough %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 2001 %G 0-07-213368-6 %I McGraw-Hill Ryerson/Osborne %O U$24.99 905-430-5000 800-565-5758 fax: 905-430-5020 %P 283 p. %T "Access Denied: The Complete Guide to Protecting Your Business Online" The introduction states that business leaders often lack the background to deal with technical security issues, and that the book seeks to fill the technical gap. Ordinarily I am wary of such claims, particularly in such slim volumes, but, after a poor start, this one works surprisingly well. Chapter one concentrates on "hackers." There is sensationalism, and there are errors, such as confusing Clifford Stoll's "wily hacker" with members of the Chaos Computer Club, but the text does at least divide security breakers into various camps, rather than lumping them all together. The discussion of viruses and malware, in chapter two, is the all-too-common unreliable mix of errors (the "Cokegift" prank is stated to be a virus) and reasonable material. A random collection of email dangers and netiquette makes up chapter three. Another miscellaneous list of Internet attacks and some misinformation (a discussion of "poisoned" cookies) is given in chapter four, but no means of protection. After this, however, the book improves. The review of encryption, in chapter five, is a clear presentation for the non-specialist. Chapter six is a reasonable guide to backup. Network security loopholes, and means of protecting them, are in chapter seven. Physical security is covered in chapter eight. Chapter nine looks at remote, wireless, and cellular security. Intrusion detection and documentation (suitable for presentation to law enforcement) is in chapter ten. The material on risk analysis, in chapter eleven, is slightly facile, but is a good accompaniment to policy development. The subtitle slightly overstates the case in terms of completeness, but this work certainly is worthy of review by any manager without a technical background, who nevertheless needs to make decisions about security. copyright Robert M. Slade, 2002 BKACCDEN.RVW 20020604 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-requestat_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-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_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. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => 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 risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>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.21 ************************
This archive was generated by hypermail 2b30 : Tue Aug 27 2002 - 17:01:57 PDT