precedence: bulk Subject: Risks Digest 22.49 RISKS-LIST: Risks-Forum Digest Weds 15 January 2003 Volume 22 : Issue 49 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 and by anonymous ftp at ftp.sri.com, cd risks . Contents: [WAY backlogged!] Computer sabotage against Venezuela oil? (David Wagner) Brace for onslaught of new viruses (NewsScan) Y2K+3 bug in Networker (William D. Colburn) Smut hits 'Army Newswatch' (Monty Solomon) How to vote for your favorite California quarter design (Fred Cohen) Hong Kong gym pulls plug on camera cell phones (Monty Solomon) Amazon not checking for sensible values (Jeremy Epstein) Google Search cached a password protected page? (Colin Sutton) Misuse of HTML comments causes missed comments (Alexander Dupuy) Biometric lunch lady (Richard Akerman) Re: PGP.COM cannot handle sales to some US residents (Stephan Somogyi) REVIEW: "CISSP for Dummies", Lawrence Miller/Peter Gregory (Rob Slade) REVIEW: "Information Security Policies, Procedures, and Standards", Thomas R. Peltier (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 14 Jan 2003 21:13:37 -0800 (PST) From: David Wagner Subject: Computer sabotage against Venezuela oil? *Oil Daily* quoted Ali Rodriguez (head of Venezuela's state oil company): "[...] we have suffered many acts of sabotage at the terminals, the refiners, and even to some well-heads in Lake Maracaibo. There were even instances of computer hacking which did a lot of damage since much of the operation is centrally controlled by computer." [Source: *Oil Daily*, vol 53, no 9, 14 Jan 2003] Does anyone know anything more? ------------------------------ Date: Tue, 14 Jan 2003 08:48:22 -0700 From: "NewsScan" Subject: Brace for onslaught of new viruses Computer users will be plagued with a host of new viruses this year, particularly worms deployed into instant messaging systems, predicts a senior technology consultant with UK-based Sophos. "Virus writers are most interested in creating the next super Windows worm, spread by e-mail or instant messaging, as these mass-mailing viruses carry the greatest impact," says Graham Cluley. "We expect more executable e-mail-aware worms this year, while more viruses are written which use instant messaging services." Sophos also expects to see an increase in the number of so-called "Backdoor Trojans," which can open up holes in operating systems so that crackers can control them from a remote location. Windows users are particularly at risk, as nine out of 10 of last year's top viruses were spread via e-mail on Windows platforms, with the most prolific being the Klez worm. So far, PDAs and mobile phones have remained largely free of virus problems, says Cluley. "There is no indication yet that we will see an avalanche of new viruses affecting mobile devices -- virus writers are not interested in targeting the mobile phone until it becomes more developed and has a bigger, common platform." [Reuters 14 Jan 2003; NewsScan Daily, 14 Jan 2003] http://shorl.com/fikunumubodri ------------------------------ Date: Fri, 10 Jan 2003 11:19:43 -0700 From: "William D. Colburn (Schlake)" Subject: Y2K+3 bug in Networker We currently use NetWorker 6.0.1.Build.174 Turbo/15 as our backup software. The first Saturday of the new year (4 Jan 2003) it appeared that only one tape was correctly labeled, and that data was appended to previous dumps on some recycled tapes. Now that the second Saturday is upon us, we watched today's tape labelling and saw that Networker is labelling the first tape correctly, but then reverting to the label scheme for the backups on 5 Jan 2002. The risk of this error is almost social engineering. Tomorrow's tapes should be labelled Full.2003.01.11.a, .b, etc. Some tapes labelled as Full.2002.01. will soon be eligible for recycling. We recycle by hand, and if the person doing it didn't know these were mislabled then we could lose recent backups. William Colburn, Computer Center, New Mexico Institute of Mining and Technology wcolburn@nmt.edu http://www.nmt.edu/tcc/ http://www.nmt.edu/~wcolburn ------------------------------ Date: Thu, 9 Jan 2003 22:34:06 -0500 From: "monty solomon" Subject: Smut hits 'Army Newswatch' The town of Webster, NY, is investigating what might have caused a program about the U.S. Army on its local cable access channel to be interrupted by about 20 minutes of explicit gay porn. [Source: John Kohlstrand, *Rochester Democrat and Chronicle*, 9 Jan 2003; PGN-ed] http://www.rochesterdandc.com/news/0108story8_news.shtml ------------------------------ Date: Tue, 14 Jan 2003 15:55:01 -0800 (PST) From: Fred Cohen Subject: How to vote for your favorite California quarter design The forms at: http://www.caquarter.ca.gov/ Allow anyone to vote on the appearance of the California quarter. According to my daughter you can vote as many times or as often as you want. Ther site uses a simple 'FORM NAME="COIN" METHOD="post"' method with parameters like 'NAME="QUARTER" VALUE="16"' (my vote) as parameters. It is indeed trivial to send in a few hundred votes per second from a modem, thousands from a DSL line or cable modem, and of course if you can afford an OC48, you can probably vote billions of times a day. I don't think they will use this as their sole decision process, but when it comes to Internet voting, I think this is a shining example of how artistic license can mint a winner. Fred Cohen http://all.net/ fc@all.net fc@unhca.com tel/fax: 925-454-0171 Fred Cohen & Associates - University of New Haven - Security Posture [However, the new quarters are apparently revitalizing coin collecting, which had grown dormant of late. So, maybe there are also plans to have a similar popularity vote for your favorite state quarter, fully expecting to report votes of 435,829,662,554 for the Rhode Island coin in hopes that it will sell more. PGN] ------------------------------ Date: Wed, 15 Jan 2003 10:58:34 -0500 From: Monty Solomon Subject: Hong Kong gym pulls plug on camera cell phones Warning: use of camera-equipped mobile phones could be hazardous to your health. That's the message going out from at least one chain of health clubs in Hong Kong, where a new generation of cell phones that can take and transmit video and still photos is raising concerns over a new crop of privacy-related issues. Physical, which operates nine gyms in the former British colony, recently posted signs in its Hong Kong facilities forbidding the use of mobile phones in locker rooms. [Source: Reuters item by Doug Young, 14 Jan 2003] http://news.lycos.com/news/story.asp?section=OddNews&storyId=623861 ------------------------------ Date: Fri, 10 Jan 2003 11:41:29 -0500 From: "Jeremy Epstein" Subject: Amazon not checking for sensible values There are lots of bugs due to not checking for sensible values, and I found this one amusing. Bret Hartman sent me a copy of his new book "Mastering Web Services Security", and I wanted to recommend it to a friend. So I went to Amazon, which tells me "Availability: This title will be released on December 31, 1969. You may order it now and we will ship it to you when it arrives." Seems to be missing a sanity check regarding the "to be published date" being in the future. ------------------------------ Date: Sun, 12 Jan 2003 22:30:46 +1100 From: "Colin Sutton" Subject: Google Search cached a password protected page? Searching for SQL help on google http://www.google.com.au/search?q=%22ANSI+SQL+CASE%22&hl=en&lr=&ie=UTF-8&oe= UTF-8&start=10&sa=N I found a link to a password controlled site http://rec.schoolsnet.syd.catholic.edu.au/ , but the page and hundreds more on that site are visible in the google cache. Can a supposedly secure site be cached on google for anyone to see if a person with access permissions uses google to search it? I don't have access to any such sites, or I'd try it. Or, perhaps the password protection was added after the site was protected. Either way, there's a risk. ------------------------------ Date: Sat, 11 Jan 2003 01:31:08 -0500 From: Alexander Dupuy Subject: Misuse of HTML comments causes missed comments My boss sent me (using some version of Outlook) some important mail with comments on several included nested messages, all of which in multipart alternative text and html. Unfortunately, my browser chose the html, which contained lots of microsoft stuff embedded in HTML comments. Apparently there's a bug in whatever version of Outlook, and the microsoft gunk sometimes omits a closing , which isn't a big deal for the microsoft HTML renderer, but is a big deal for other HTML renderers, since it leaves the HTML comment open, including all of the message text up to the end of the next HTML comment, just before the body text of the first "Original Message". For microsoft HTML renderers, the missing bit makes no difference, as it is displaying the data even though it is in a comment (I guess it recovers okay from the missing endif), but for people with other HTML renderers, the comment is completely invisible. I only saw the included messages, but none of my boss's comments (the non-HTML kind). I only realized that this had happened when one of my co-workers (who uses emacs to read his e-mail) replied to the message, and included some text that I hadn't seen. ------------------------------ Date: Thu, 09 Jan 2003 21:53:02 -0500 From: Richard Akerman Subject: Biometric lunch lady In what seems like a remarkably elaborate solution to a simple problem, "students will be charged for their lunches with a retina scanning device" at a school in England starting in September. http://www.salon.com/tech/wire/2003/01/09/uk_school/ This brings a whole new meaning to "stealing someone's lunch money". ------------------------------ Date: Sun, 5 Jan 2003 23:04:29 -0800 From: Stephan Somogyi Subject: Re: PGP.COM cannot handle sales to some US residents (Kabay, R-22.46) It distresses me acutely that Dr Kabay did not have the most friction-free purchasing experience possible -- my inner Ferengi does so hate it when we hinder a customer from exchanging money for one of our fine products -- and while the above provides all the necessary clues, Dr Kabay unfortunately does not draw the correct conclusions. As he points out, Dr Kabay is using his StarBand account. This is a satellite-based ISP with a footprint that covers the continental US as well as quite a bit of geography surrounding it. is a helpful source for determining the service's reach. I am not a professional cartographer, yet it appears to my layman's understanding of geography that one of the above explicitly named seven countries quite likely finds itself within a satellite footprint that extends out to the US Virgin Islands. Since PGP Corp is located in California, we are subject to US laws. These include the export restrictions overseen by the Department of Commerce in the form of its BIS, the Bureau of Industry and Security, formerly known as the BXA, the Bureau of Export Administration. If we guess right about a given satellite ISP user, we generate about 40 bucks in revenue. If we guess wrong, we're looking at $10K+ in fines, and are further subject to administrative actions up to and including "no more export to anywhere for you, ever." As risk assessment goes, this is not a hand-wringer. >The customer service agent was very nice and obviously embarrassed >about this situation and admitted that there are no measures in >place for dealing with such a technical glitch. There is no technical glitch. Evidence clearly suggests that our customer service agent may not have had all the facts available to her at the time Dr Kabay called, but the system functioned as designed. We "fail closed" rather than "fail open" based on having examined the risks inherent in delivering export-controlled software to a world-wide audience. If we cannot ascertain your whereabouts with a reasonable degree of certainty (and StarBand doesn't provide that information as part of the reverse-resolved IP address), we will not deliver software to you and expose ourselves to some rather substantial liability. >1) Check the IP address BEFORE the user fills out all the forms and >the credit card gets debited. I'm delighted that Dr Kabay suggests this course of action, since it provides the opportunity to expose another risk that we've had to take into consideration. It is not feasible to perform such a check before the user fills out the form since it opens us up to a financial denial of service attack. Performing the necessary checks to determine a buyer's suitability for sale costs PGP Corp money per check. The process involved is not a simple matter of reverse-resolving an IP address. If we were to perform the requisite check prior to accepting the credit card, it would be a trivial exercise to launch an attack that's quite expensive to us. >2) Send the user a CD-ROM to the US address listed in the order. We are currently investigating this as an alternate delivery method. >3) Ask the user for strong evidence that they are in fact living in >the US: e.g., [...] I cannot imagine that Dr Kabay meant this suggestion seriously. As a non-governmental organization, we have no ability to verify a given driver's license's validity or the whereabouts of its holder, nor are we able to divine what an "appropriate US fax machine" is. Moreover, it strikes me as ironic to suggest that a company such as PGP Corp, which is committed to security and privacy, put itself in a position where it has to make a determination about what constitutes an authoritative means of location identification, and then verify it. >b) ask for other corroborating evidence such as a US address >listing in university or corporate Web sites. Had Dr Kabay attempted to purchase and download our software from a university or corporation with an unambiguous location, I daresay he would've succeeded. >RISKS of assuming your automated system is perfect: you lose sales. We assume no such thing. Our system did, however, operate precisely as it was supposed to in this instance. RISKS of not erring on the side of caution when it comes to the law: gaining the concerted attentions of the BIS. Stephan Somogyi, Director of Products, PGP Corporation ------------------------------ Date: Tue, 10 Dec 2002 08:02:38 -0800 From: Rob Slade Subject: REVIEW: "CISSP for Dummies", Lawrence Miller/Peter Gregory BKCISPDM.RVW 20021029 "CISSP for Dummies", Lawrence Miller/Peter Gregory, 2002, 0-7645-1670-1, U$39.99/C$59.99/UK#29.95 %A Lawrence Miller %A Peter Gregory peter.gregory@hartgregorygroup.com %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 2002 %G 0-7645-1670-1 %I John Wiley & Sons, Inc. %O U$39.99/C$59.99/UK#29.95 416-236-4433 fax: 416-236-4448 %O http://www.amazon.com/exec/obidos/ASIN/0764516701/robsladesinterne %P 408 p. + CD-ROM %T "CISSP for Dummies" A 'cheat sheet' is bound into the front of the book. It offers some general advice for taking the CISSP (Certified Information Systems Security Professional) exam, the most useful aspect of which is to prepare. Most of the tips are vague, such as the suggestion to budget your time, or review CISSP resources, without any information about what factors should be considered in time management or where to find resources. Some tips are overly specific, such as the recommendation that you bring a big bottle of water. (Yes, six hours is a long time for the exam, and, yes, you may need refreshment. The tip does not mention that proctors vary in rigour when applying the exam regulations, and may not allow bottles of water at the test tables. Besides which, only one person may be excused from the room at any one time.) Part one reviews the CISSP exam itself. At the beginning of chapter one, the authors point out that some CISSP study guides are too hard, and some CISSP study guides are too soft, but this book is just right. Then it moves on to information about (ISC)^2 (the International Information Systems Security Certification Consortium), arrangements for the exam, and some study tips. The material is more up-to-date than in other CISSP study guides, but the text is badly written, duplicating content and repeating itself, possibly because the structure and organization is weak. The suggestions and information are reasonable, although occasionally questionable: the recommendations for study guides and practice exams are rather weak. Chapter two briefly lists the ten domains of the common body of knowledge (CBK), and is really only an expanded table of contents for the chapters in the next section. Part two describes the ten domains in detail. Chapter three covers most of access control, but unevenly. Given the constraints that the authors themselves mention (the CISSP CBK is a mile wide and an inch deep), too much space is devoted to a simplistic set of password choice rules, an excellent (but, in this situation, overlong) review of Kerberos, and a number of jokes which are not going to help candidates remember important points, and may very well confuse the issues. Some material is problematic, such as the discussion of security "domains" that follows the Microsoft networking model rather than the Bell-LaPadula derived structure that the CBK requires, and a baffling non-explanation of the lattice model. (There are also a number of perplexing inclusions, such as a cross-reference to cryptography in the introduction to single sign-on systems.) Telecommunications and network security is presented in chapter four. The authors have used the OSI (Open Systems Interconnection) model to structure the discussion of various technologies: an interesting concept, but one which is flawed by the fact that a number of topics are placed in the wrong level. (Media access and packet switching, for example, are listed in the data link layer, rather than the physical and network layers, respectively.) There are also problematic references to "native" PPP (Point-to-Point Protocol) encryption, and an assertion that ICMP (Internet *Control* Message Protocol) packets are not required for network operations. The basics of security management are covered in chapter five, but very tersely. The major standards are not listed here: the Common Criteria is mentioned briefly in chapter eight (security architecture) but British Standard 7799/ISO (International Standards Organization) 17799 is not listed at all. The set of roles and responsibilities is short and risk analysis terms are not well defined. This must be considered a serious weakness in the book, since security management is very important in the CISSP exam. Application development is dealt with briefly and poorly: again, this is an area where many CISSP candidates do need extra help, and they won't get it here. System development methods are not discussed at all, and the malware section is full of errors. (Each chapter lists a set of books for extra research: I should note that neither of the virus books listed at the ISC2 site appear on the list for this chapter. In fact, the bibliography is rather short overall: Krutz and Vines "The CISSP Prep Guide" (cf. BKCISPPG.RVW) which is not much better than the current work, is listed in every set.) There are also odd inclusions from other domains, such as almost a full page devoted to the SYN flood attack, which was adequately explained in a paragraph in chapter four. The material on cryptography, in chapter seven, lists all the terms and technologies, but has poor or non-existent explanations, mathematical errors, and the authors obviously do *not* understand S-boxes. (The process described would not allow for decryption.) There is too much text about CPUs (Central Processing Units), and too little on distributed systems, formal models, and the various evaluation criteria in chapter eight's review of security architecture. Operations security, in chapter nine, seems to be a collection of random topics, with a fair concentration on audit logs. Chapter ten's overview of Business Continuity Planning (BCP) is not bad, although a bit shy on details. (The vital topic of backups, for example, is mentioned only long enough to say that you should have one, and the various types, with varying strengths and weaknesses, are not discussed at all.) Law, investigation, and ethics is reasonable, although the list of specific privacy laws is probably not too helpful (and I rather suspect that the authors got taken in by the "Desert Storm Virus" myth). Most of the material on physical security, in chapter twelve, appears to have been copied from some other source without much understanding: the sections on visibility, capacitance sensors, and UPSes (Uninterruptible Power Supplies) are among those that contain errors or seem to miss the major points. Part three is the usual "dummies" "part of tens." Chapter thirteen relists the ten domains. (Didn't we do this already?) Ten other security certifications are recorded in chapter fourteen. Web sites are given in chapter fifteen: three are actually useful. The cheat sheet and chapter one are reprised in sixteen and seventeen. One of the books listed in chapter eighteen ("Security Engineering," by Ross Anderson, cf. BKSECENG.RVW) would be very useful for exam candidates. Sample test questions are a big part of every CISSP study book (in the case of Peltier and Howard's "The Total CISSP Exam Prep Book," in fact, the *only* part). This book has both its own set of questions, and a set from the Boson exams. As I have said elsewhere, the Boson exams are not necessarily wrong, but they are far too simplistic to be considered adequate preparation for the CISSP exam, and the answer guides are completely tied to "Secured Computing" (cf. BKSCDCMP.RVW). If any set of questions are simpler, and therefore less useful, than the Boson set, they are the ones listed in this book. And, like the Boson collection, the answers are completely self-referential. Like Andress' "CISSP Exam Cram" (cf. BKCISPEC.RVW), this text does sometimes simply list the terminology, although Miller and Gregory are somewhat more complete and do provide greater explanations of the domains themselves. It would be hard to make a distinction between this volume and "Secured Computing": Miller and Gregory provide *some* outside references but Endorf makes fewer errors. As previously noted, Krutz and Vines do not give the reader much in the way of explanatory material, but they do cover the domains more comprehensively than the current work. Harris' "CISSP All-in-One Certification Exam Guide" is, as noted (cf. BKCISPA1.RVW), the one guide that might get you through the CISSP exam, albeit not necessarily with high marks: Miller and Gregory might get you through, but only if you stood a pretty good chance without the volume. copyright Robert M. Slade, 2002 BKCISPDM.RVW 20021029 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Wed, 4 Dec 2002 08:43:30 -0800 From: Rob Slade Subject: REVIEW: "Information Security Policies, Procedures, and Standards", Thomas R. Peltier BKISPPAS.RVW 20020923 "Information Security Policies, Procedures, and Standards", Thomas R. Peltier, 2002, 0-8493-1137-3 %A Thomas R. Peltier %C 920 Mercer Street, Windsor, ON N9A 7C2 %D 2002 %G 0-8493-1137-3 %I Auerbach Publications %O U$69.95 +1-800-950-1216 auerbach@wgl.com orders@crcpress.com %O http://www.amazon.com/exec/obidos/ASIN/0849311373/robsladesinterne %P 297 p. %T "Information Security Policies, Procedures, and Standards" Chapter one provides vague meanderings about information protection fundamentals. The author's opinion about how to write is given in chapter two. In the ultimate triumph of style over substance, this drafting advice is given before any examination of actual policy development. Chapter three defines policy and some related topics with lots of verbiage and overly lengthy examples. There are lots of sample mission statements in chapter four, although it is not really apparent why we are talking about this particular topic. The structure of chapter five, dealing with standards, is very confused, and the purpose of the examples given is unclear. (There is also an extremely odd assertion that standards, which are by definition rigid, must be "flexible.") We are given more writing advice, supposedly in aid of procedures, in chapter six. Chapter seven talks about information classification for a few paragraphs and then lays out a thirty page example. Random security thoughts and banal training ideas make up the security awareness program in chapter eight. Generic project management advice is in chapter nine. Chapter ten contains suggested topics for a security policy. What the book said is repeated in chapter eleven. The appendices include a very short sample policy, and a policy development checklist. Barman's "Writing Information Security Policies" (cf. BKWRINSP.RVW) provides far better advice on both the process and the topics to be covered in creating a security policy. Even "Information Security Policies Made Easy" (cf. BKISPME.RVW) is better, for all that people tend to misuse it. Peltier's book provides little of use to the harried security manager. copyright Robert M. Slade, 2002 BKISPPAS.RVW 20020923 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ 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. .MIL users should contact (Dennis Rears). .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.49 ************************