RISKS-LIST: Risks-Forum Digest Saturday 1 September 2001 Volume 21 : Issue 64 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/21.64.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Temelin nuclear plant software problem (Pete Mellor) Blame the victim: vandalized Web sites may be liable for damages (NewsScan) More risks when driving (Martin Cohen) Risks of "pre-owned" computers (Nick Brown) Microsoft Reader e-books broken (David Farber) AOL silently dropping mail (Simon Waters) eBay fails to protect email addresses of users (Vassilis Prevelakis) Re: Avoiding prosecution of the DMCA (A J Stiles) Risks and madness on the BT Cellnet site (Mike Perry) Not such an equal opportunity (Bill Lamb) Re: Code Red 9? Code Crimson (Bob Frankston) Risks of outsourced check verification (Peter Simpson) Can't hold room, but can bill (Sandy Antunes) Caller ID vs. ANI confusion, again (William Kucharski) Re: Mixing advertising and credit-card activation (John Clarke) REVIEW: "Information Security Management Handbook", Tipton/Krause (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 27 Aug 2001 15:04:35 +0100 (BST) From: Pete Mellor <pmat_private> Subject: Temelin nuclear plant software problem The following is one item from the regular news digest produced by the students of Charles University, Prague:- CAROLINA No 429, 24 Aug 2001 FROM THE EVENTS OF THE PAST TWO WEEKS (August 9 - August 22) Temelin up Again, down Again The Temelin nuclear power plant was activated again 12 Aug 2001 after three months of repairs to a vibrating turbine (see Carolina 428). The relaunch of Temelin provoked hostile reactions from some Austrian politicians and anti-nuclear and environment activists. News leaked 15 Aug about new vibrations in the turbine, which caused an 18-hour shutdown. However, plant officials claimed the shutdown was used to "balance a rotary part in the turbine." The reactor 19 Aug was automatically switched off due to a software error in a steam-delivery regulator. Temelin opponents claimed this shutdown was the 23rd since the beginning of operating tests. According to Temelin management, the shutdowns are a normal part of the testing procedure and are not related to nuclear safety problems. Temelin CEO Frantisek Hezoucky said Temelin is exceptional only in one respect: it is the very first nuclear power plant where its testing is broadcast live to the public. STUDENTS' E-MAIL NEWS FROM THE CZECH REPUBLIC Charles University in Prague, Faculty of Social Sciences Smetanovo nabr. 6, 110 01 Prague 1, Czech Republic e-mail: CAROLINAat_private ISSN 121-5040 tel: (+4202) 22112252, fax: (+4202) 22112219 ------------------------------ Date: Mon, 27 Aug 2001 11:00:13 -0700 From: "NewsScan" <newsscanat_private> Subject: Blame the victim: vandalized Web sites may be liable for damages Some legal scholars are suggesting that a Web site vandalized by hacker attacks may itself be legally liable if its customers suffer damages and if the site was negligent in maintaining security. Law professor Margaret Jane Radin of Stanford University predicts: "A court is going to say it is negligent of you not to implement preventative measures if they are reasonably effective and affordable." No reported court decisions have dealt with the issue, but Radin says that lawsuits in the near future are highly likely to be lodged against companies and network providers targeted by "denial of service" attacks. [*The New York Times*, 24 Aug 2001; NewsScan Daily, 27 August 2001 http://partners.nytimes.com/2001/08/24/technology/24CYBERLAW.html] ------------------------------ Date: Sat, 18 Aug 2001 01:31:48 GMT From: Martin Cohen <mjcohenat_private> Subject: More risks when driving *The New York Times* e-mail version contained an ad offering to teach you a language while you are driving. Imaging trying to learn an irregular verb while negotiating difficult traffic. [You might drive right through a subjunction. Incidentally, someone was jogging toward me this morning when his cell phone rang. At least he had the good sense to stop running. PGN] ------------------------------ Date: Sat, 1 Sep 2001 13:55:20 +0200 From: BROWN Nick <Nick.BROWNat_private> Subject: Risks of "pre-owned" computers The BBC reports that "confidential files containing the identities of alleged paedophiles and their victims were found on a second-hand computer bought from Bristol University". Full story at http://news.bbc.co.uk/hi/english/uk/newsid_1519000/1519889.stm Not a new RISK, but the first time I've seen this particular combination. Does *your* local social welfare department, public hospital, or police station have a statutory duty (in the interest of the taxpayers) to sell, rather than destroy, old equipment ? And if so, is there a mandatory procedure for securely erasing the hard disk first ? Nick Brown, Strasbourg, France. ------------------------------ Date: Fri, 31 Aug 2001 23:51:19 -0400 From: David Farber <daveat_private> Subject: Microsoft Reader e-books broken An anonymous programmer has found a way to decrypt Microsoft Reader e-books on Windows PCs, but has not released it. [Source: Breaking Microsoft's e-Book Code, By Wade Roush, Technology Review, 30 Aug 2001, http://www.technologyreview.com/web/roush/roush083001.asp; PGN-ed; Dave has been predicting this, but then all lame protection seems to be easily broken, relying on the DMCA for protection. Dave's archives are at http://www.interesting-people.org/ . PGN] ------------------------------ Date: Sat, 25 Aug 2001 23:49:09 +0100 From: Simon Waters <Simonat_private> Subject: AOL silently dropping mail I received reports from an AOL user of e-mail's not getting through. Checking log files show that AOL's mail server had received all the messages correctly. Queries to AOL's postmaster account received no response. Web pages run by AOL users suggest the cause of this is that I may have triggered a "suspicious relaying" trap with the AOL server. Assuming this is the case it is interesting that AOL choose to drop the mail silently, when all the information required to make such a decision is available to the mail transport agent before the body of the mail is sent. Thus AOL could choose to refuse the mail politely, using less bandwidth, and informing the sender of a problem, but prefer to waste bandwidth and delete the e-mail silently. The Risk? Assuming AOL cares enough about their subscribers e-mail not to delete it without notifying sender or recipient, or answer questions on the topic. The only way I can see to mitigate the risk is to switch to another ISP. +44(0)1395 232769 Moderated discussion of teleworking at news:uk.business.telework ------------------------------ Date: Sun, 26 Aug 2001 18:01:09 -0400 (EDT) From: Vassilis Prevelakis <vassilipat_private> Subject: eBay fails to protect email addresses of users Normally eBay will not disclose the email addresses of its users. When you wish to send email to an eBay user, eBay provides a proxy service accepting the email and then forwarding it to the recipient. However, if the mailhost for the recipient is down or unavailable, the sender will get a warning email saying that the original message could not be delivered but the system will go on trying, WITH THE E-MAIL ADDRESS OF THE RECIPIENT. Another example of not thinking things through. Vassilis Prevelakis, Distributed Systems Laboratory, Univ. of Pennsylvania Philadelphia, PA 19104-6389 +1 215 898 0375 vassilipat_private ------------------------------ Date: Sun, 26 Aug 2001 11:59:03 +0100 From: "A J Stiles" <ajs2at_private> Subject: Re: Avoiding prosecution of the DMCA (Re: Petrou, RISKS-21.62) But you are forgetting the law of Dual Criminality. A person can only be extradited from one country to another if what the person did was recognised as a criminal offence in the country where they did it. Since pointing out a security vulnerability is not a criminal offence in most countries, extradition can be refused. (Otherwise anyone who drinks alcohol could be extradited to any muslim country and executed!) Of course, the USA could act illegally (as it has done on many occasions in the past). That would technically be an act of war ..... A J Stiles <ajs2at_private> http://pages.zoom.co.uk/~nineladies/ ------------------------------ Date: Fri, 24 Aug 2001 18:39:42 +0100 From: "Mike Perry" <PERRYMat_private> Subject: Risks and madness on the BT Cellnet site I've just registered with the BT Cellnet site in order to be able to view my mobile phone bill online. I had to choose some authentication items, and I quote here from the website: ====================================================== For security purposes our on-line services are password protected -- in order to use them you need to register by providing a username, password, a memorable item, and a password hint. Your Username and Password must be unique to yourself. Try to use something memorable - you will need to use these every time you logon. Your Password will expire every 90 days and you will be required to choose a new one. You will be automatically prompted to change your password whenever you logon after the 90 day period has expired. To make your password easier to remember you can use the same password but add a different number each time a change is needed. For example password1, password2, password3 and so on. ====================================================== Looks like a well-known risk is not as widely-known as we might hope. But wait -- it now leaves the realm of "bad", and enters the "mad": ====================================================== The Password Hint is a word or phrase that you can choose to remind you of your password should you forget it. For example if your password is your pet's name then the password hint could be 'pet's name'. The Memorable Item is something that you will need to supply whenever you need to see your Password Hint. Again try use something that is linked to, and therefore will remind you of, your password and password hint. ====================================================== The usual way that Web sites provide for forgotten passwords is to set up a challenge-response, where the user gives a question that should be asked if they forget their password, and the answer they will give to prove who they are. So you can pick things which you are (fairly) sure wouldn't be known by a miscreant, such as "what's the serial number on the back of your watch?" or "what was the name of your first girl/boyfriend?". This has always seemed to me to be a secure enough system where you don't fear network snooping etc. But how am I expected to remember "something that is linked to, and therefore will remind you of, your password and password hint" in order to help me when I've forgotten my password? I know - maybe I'll write it down...... Mike Perry, IBM UK Webserver Group ------------------------------ Date: Fri, 17 Aug 2001 17:22:30 -0500 From: Bill Lamb <blamat_private> Subject: Not such an equal opportunity I recently attempted to apply online for a position with Tarrant County College in Fort Worth, Texas. The first screen in the Web form was for Affirmative Action purposes and required such items as full name, address and Social Security number. Fortunately, I noticed there was no indication the connection had been secured: no warning from my browser and no "locked" icon in the browser window. I quit the site and e-mailed the school's HR department to report the problem and ask for a "snail mail" address to which to send my resume. Later that day I received a response from an HR employee stating the school accepts applications _only_ via the online forms, but they are indeed secure. Alternatively, I was welcome to visit the school's library to apply online using one of their machines if I still felt uncomfortable in doing so over the Internet. I again e-mailed, restating the problem with their supposedly secure connection, and noting that since I lived more than a hundred miles away I wasn't likely to visit the campus simply to fill out a form. Two days later I received a reply stating a "supervisor" would contact me shortly. That was five days ago. No supervisor yet. The risks of such a Web connection that may or may not be secure are obvious. But the hidden - and greater - risk here lies in the institution's apparent blind slavery to this new technology. While no doubt making their jobs easier, the policy of only accepting applications online closes off employment opportunities to an untold number of people simply because they may not have access to the Internet or live within bus, car or walking distance of the campus. Not such an Equal Opportunity Employer, after all, though I know that wasn't their intent. Bill Lamb blamat_private www.wmlc.net ------------------------------ Date: Sat, 25 Aug 2001 19:07:02 -0400 From: "Bob Frankston" <rmf2gRisksat_private> Subject: Re: Code Red 9? Code Crimson (McDonald, RISKS-21.62) By this reasoning, one shouldn't buy software from companies that write software in languages that don't make buffer-length checking the norm such as C and it's variants including C++. Languages such as Java, C# and PL/1 don't suffer this unless programmers get too clever and try to squeeze out that extra nanosecond that an indirection may entail. Remember that a computron saved means hours wasted! [Yes, I know this is a more complicated topic, but a vow of poverty isn't the answer to all problems -- not that I like being put in the position of defending Microsoft.] ------------------------------ Date: Tue, 14 Aug 2001 07:32:12 -0400 From: Peter_Simpsonat_private Subject: Risks of outsourced check verification I recently tried to pay for some clothing with a personal check at a large, national clothing store. I was asked for a driver's license, which I produced, and the sale went through normally. I then went to a different department, and, again, tried to pay for more clothing with a check. Produced my license. The clerk told me the "transaction had been declined". I asked why, and she handed me a cash register receipt with a code number and an 800 number. I asked her if I could use her phone to call the number (hoping to straighten out whatever the problem was) and was told they could not use it to call outside numbers. When I got home, I called the number. It was a third party check approval service. The person on the other end of the line asked for my ID (license) number. She then told me that the transaction had been declined because of "unusual check-writing activity". I asked her exactly what that meant. She told me that they had just approved my check number 202 and then tried to use check number 221. The first clerk had transposed two digits while manually entering the check number. So, my second check was declined. Of course, this "wasn't their fault", and "wasn't the first clerk's fault, either...people make mistakes". My comment that this mistake could easily have been cleared up if I had been allowed to know why the check had been declined fell on deaf and uncaring ears. I liked it better when the manager was called and scribbled his initials on the check. Peter Simpson ------------------------------ Date: Fri, 17 Aug 2001 16:03:58 -0400 From: Sandy Antunes <sandyat_private> Subject: Can't hold room, but can bill I had a reservation (via phone) with the Hyatt for a trade show. Later I cancelled the credit card used to reserve it, so I called the Hyatt to give them a new card number. Problem 1: I couldn't find the confirmation number they'd given me. Problem 2: They couldn't find a reservation for me, and insisted I did not have one. And the hotel was booked for the entire trade show. Solution (mine): Booked at another hotel. ... time passes ... I get a statement from the _cancelled_ credit card, listing a charge by the Hyatt for 1 day's stay. Oh oh. I call the Hyatt. The clerk is easily able to call up my record using the credit card number and verify that yes, I had a reservation and yes, I hadn't called to cancel it so I had to pay for 1 night. Oh, and they'd mistyped my name. Which to me explained why they'd 'lost' my reservation in the first place. He got manager approval to refund the credit charge because it lacked a "Cancellation Number", and it'll be at least one billing cycle before it goes through. So they couldn't find my information when I wanted to stay, but could find it to bill. Risks? Reservation clerks not believing customer, inconsistent procedures and lookups, inaccurate data entry still being accepted by credit card company, cancelled card not rejecting charges, probably others. Sandy Antunes <aantunesat_private> ------------------------------ Date: Sat, 18 Aug 2001 01:50:02 -0600 From: "William Kucharski" <kucharskat_private> Subject: Caller ID vs. ANI confusion, again In Risks-21.57, Mike Tuffs writes about his credit-card company getting his phone number despite his having Caller ID blocked. Once again, there are two distinct and COMPLETELY SEPARATE systems that deliver calling phone numbers information to recipients. The system used for toll-free numbers (which the author undoubtedly used to call his credit card company) as well as for long-distance call billing and for 911 services is called ANI. ANI CANNOT be blocked, at least not without making a significant (and likely questionably legal) effort to thwart the telephone system. I suspect the answer about ignoring the "ignore" bit is just a script they give the customer service people, or the agent was just making it up. The bottom line is that your calling number is delivered to the recipient of any toll-free call you make, whether in real time or via a billing statement, REGARDLESS of whether you have Caller ID blocked or not. William Kucharski <kucharskat_private> [Noted by quite a few readers, including the following. TNX. PGN] ------------------------------ Date: Fri, 17 Aug 2001 16:44:13 -0400 From: "John Clarke" <jclarkeat_private> Subject: Re: Mixing advertising and credit-card activation [...] An interesting story, and possibly an urban legend, about ANI. When computerized call centers were becoming the norm, a major credit-card company decided to use ANI to help the operators handle customer calls in a more friendly manner. When a customer called from their home number, the computers would automatically match the number to the account holders name, even before the operator had picked up the call. The operator would then, upon hearing the callers voice, respond with <Mr., Ms.> Account Name, how can I help you? Callers were so disturbed by the fact that the operator knew who they were before they had identified themselves that the credit-card company eventually told the operators to stop using this technique. They still know who you are (or are likely to be), but withhold the info and allow you to provide it before they use it. Customers are much happier with this method. When you call an 800 number and reach a call center, your file has likely already appeared on the agent's computer screen, whether they let you know that or not. ------------------------------ Date: Mon, 27 Aug 2001 12:08:32 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Information Security Management Handbook", Tipton/Krause BKINSCMH.RVW 20010609 "Information Security Management Handbook", Harold F. Tipton/Micki Krause, 2000, 0-8493-9829-0/0-8493-0800-3, U$155.00 %E Harold F. Tipton haltipat_private %E Micki Krause Micki.Krauseat_private %C 2000 Corporate Blvd. NW, Boca Raton, FL 33431 %D 2000 %G 0-8493-9829-0, 0-8493-0800-3 %I Auerbach Publications %O U$155.00 800-272-7737 auerbachat_private slintonat_private %O available separately 0-8493-9829-0 $95.00 0-8493-0800-3 $59.95 %P 2 vol., 711 p. + 626 p. %T "Information Security Management Handbook, Fourth Edition" As an overview for the CISSP (Certified Information System Security Professional) CBK (Common Body of Knowledge), this work covers a vast range of topics. The CBK, and the book, is divided into ten domains, covering access control systems, telecommunications, security management, systems development, cryptography, security architecture, operations security, business continuity, law and ethics, and physical security. The text provides some excellent articles, some of which are general but detailed overviews, and others that address particular problems or new technologies. However, even with fifty nine articles and over thirteen hundred pages there are gaps, some surprisingly basic. The quality of the articles can vary widely. The first essay, on biometrics, provides an admirable review of the subject, as well as some solid, practical, and useful detail information. The next paper is a rather odd treatment of single sign-on, addressing the concepts well, but in a disjointed manner that makes reading or studying difficult. Following those comes a paper ostensibly dealing with securing connections to external networks. It collates some generic and vague descriptions of a variety of topics, none of which are particularly informative or reliable. (A two-page section on computer viruses contains numerous glaring and significant errors. Personally, I continue to find it appalling that general security texts deal so poorly with this topic.) Other areas covered are firewalls (terse), perimeter security for the Internet (again, but this time with excellent technical information on TCP/IP specifics), extranets (doctrinaire), firewall management (very useful for planning), the OSI (Open Systems Interconnections) network layer security model (questionable utility), the OSI transport layer security model (not much better), application layer security (interesting but undetailed), communications and security protocols (broad overview, concise but fills in some common gaps), security awareness training (reasonable points for success), security architecture (brief but basic), IPsec (good overview), risk analysis (thorough but perhaps a trifle pedantic), trade secret protection (an interesting twist), information security for healthcare (a tad verbose and US-centric), security for object-oriented databases (listing proposals), fundamentals of cryptography (very clear explanations of the math involved), key management (great review of principles, and amusing anecdotes from history of the *wrong* ways to manage keys), Kerberos (extensive coverage of both details and concepts), PKI (Public Key Infrastructure, a quick guide to the basics), microcomputer and LAN security (good concepts, overly optimistic, oddities in details), trapping intruders (quick concepts), Java security (quick basics), business continuity planning (a new process), restoration after disaster (general review), computer crime investigation (good coverage of many aspects), Internet ethics (emphasis on privacy), jurisdictional issues (miscellaneous), intrusion detection (concepts and evaluation points), single sign-on (opinion this time), authentication services (concepts and amusing overview), email security (concept review), ATM (Asynchronous Transfer Mode) security (without really discussing security), remote access (background fundamentals), sniffers (concepts and details), enclaves (firewalls within), IPsec (good details), penetration testing (very basic policies), policy (some good points but quite random), the security business case (opinion), PeopleSoft security (as for any major database), World Wide Web application security (reiteration of general security planning with a few Web specifics), common system design flaws (an important set), data warehouses (standard system development advice with limited security relevance), PKI (simplistic), introduction to encryption (a good one), new models for cryptography application (useful for planning), cryptanalysis (decent review of terminology), message authentication (detailed), UNIX security (concepts and tools), hacker tools (not very detailed), malicious code (theoretical and incomplete), business impact assessment (after Y2K), computer crime investigation (document everything), computer incident response teams (CIRTs, vague), intrusion detection (vague and repetitious), and operational forensics (retain evidence and data). Observant readers will have noted a fair amount of duplication in that list. In fact, the reiteration of content is worse than appears here, since many topics rely on others, and certain basic ideas (Kerberos operations, the Diffie-Hellman public key system, and risk management, for three examples) recur in a variety of other discussions, with differing levels of detail. As in any work this size a number of outright bizarre mistakes have occurred, like the table showing the file structure of an authentication database, which has been swapped with the structural diagram of a completely different authentication system. This is the closest thing there is to a textbook for the CISSP exam. It is fairly easy to see which sections have been reproduced in the ISC(2) (International Information System Security Certification Consortium) course (in some cases complete down to specific errors). Intriguingly, there are sections of the course that previously were covered by the third edition, and which do not appear in any significant form in this work. (An example is the discussion of the standard formal security models, such as Bell-La Padula and Clark-Wilson.) It should be noted that there is a significant difference in character between the two volumes. The first volume deals with topics that are closer to the heart of security, and the essays are generally more valuable to the practitioner. Volume two contains papers over a wider range of subjects, many of which (with the notable exception of the pieces on cryptography) have little or no relevance to security beyond fundamental concerns that are well covered elsewhere. Book one will be useful to the CISSP candidate and any specialty security worker: book two may be of interest to a narrower group of senior security executives and theorists, and, ironically, a wider audience of those interested in newer technologies in general. The quantity of good information that is contained in the work is definitely worth the price, but there could easily be a wholesale pruning of deadwood. copyright Robert M. Slade, 2001 BKINSCMH.RVW 20010609 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 12 Feb 2001 (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 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 20" for volume 20] 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 21.64 ************************
This archive was generated by hypermail 2b30 : Sat Sep 01 2001 - 15:05:02 PDT